-
Notifications
You must be signed in to change notification settings - Fork 21
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
feat: Add support for -x/--exclude-lines. #58
base: main
Are you sure you want to change the base?
Conversation
|
||
frame = frame.f_back # type: ignore[assignment] | ||
@functools.lru_cache(None) |
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.
without this cache, I saw a ~2s slowdown relative to the current impl.
5.9s without exclusions
6.1s with exclusions and cache
8.8s with exclusions no cache
10.5s with coverage
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.
Hi, thank you for your pull request! Please check out my questions and/or make the changes requested.
a4e4379
to
a447abe
Compare
Sorry, I think my original commit must have had some editor auto-formatting or something going on. I definitely was not consciously going through and removing annotations and altering those version-constrained blocks! Updated to be (hopefully now) only the actual changes related to the enhancement. |
Attempts to fix #26
I integrated the regex matching into the line-inclusion loop (Thus it works by excluding excluded lines from the total set), but it occurred to me afterwards, that it could perhaps instead be integrated similarly to
_add_unseen_source_files
. There, you're already scanning a bunch of files, compiling them, and adding their lines. It could work in reverse, where it scans all the files, compiles them, and adds matching lines to the "seen" set.I'm not familiar enough with the code to know if one would make more or less sense than the other, but I think the way I have it implemented now is at least intelligible and seems to be performant.
I tried to defer imports to expensive modules (like re/inspect) up to the point of the
exclude_lines
feature being utilized. I dont see any slowdown when not making use of the feature, but a ~0.2s slowdown when making use of the feature on a ~6s test run (~10k LOC, since I figure it scales worse with numbers of code objects scanned).I wasn't able to get all the tests running locally, it seems unrelated to my changes, and that it might be some environment specific thing that I'm not sure what I need to do; but I can't say for certain.
Also, I dont love this feature being purely given by command line options. if you're into this feature, i would ideally like to follow it up by (even optional) reading from
pyproject.toml
for atool.slipcover
setting (for this at a minimum)