-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reworked modules filtering process #1645
Reworked modules filtering process #1645
Conversation
Here the code example with comparison https://github.com/BlackGad/Coverlet.Issue |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
I looked at the PR and think this is good. Thanks a lot @BlackGad 🙏 . I only refactored some minor things to increase readability and will see if I can add some more tests. Will push my changes somewhere next week and then we can merge. |
Thank you! Please do it asap) Kinda very annoying issue :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot 🙏. LGTM 👍
Can't wait to see release version to test. Thank you for merging! |
Recently, we encountered a performance issue with Coverlet during our CI pipeline processes.
Before executing
dotnet test
, we preprocess our CI build files to generate a runsettings file. This file specifies which assemblies to include and exclude based on pattern matching.The output directory ends up containing over 350 assemblies, including framework ones. Within this, the include section lists 54 patterns in the format [Assembly1]*,[Assembly2], while the exclude section contains 301 patterns, also specified in a similar manner.
Runsettings example:
The initial step of the testing operation involves Coverlet filtering the modules it needs to instrument. Using the aforementioned runsettings for filtering resulted in a significant delay of 50 seconds, primarily due to the inefficient implementation of the include and exclude filters. This Pull Request addresses and resolves this issue, reducing the filtering time to just 200 milliseconds.
Although I believe there's room for further optimization, particularly with type filtering, I consider that an objective for future development. I respectfully request a review and approval for merging this PR.
closes #1646