# general


08/30/2021, 9:33 PM
Hi all! I'm trying to add test coverage for my repo that already uses pants, and I want to add some configs to exclude some 3rd-party code cuz I don't want code coverage reported on them. So I created a
file to do this. However I noticed that once I added this file, my test runs 10x slower. What is the problem and how can I fix it?
This is what my .coveragerc file looks like rn:
Copy code
# .coveragerc to control
# This is required for pants to work
relative_files = True
# Measure branch coverage in addition to statement coverage
branch = True

# Regexes for lines to exclude from consideration
exclude_lines =
    # Have to re-enable the standard pragma
    pragma: no cover

    # Don't complain about missing debug-only code:
    def __repr__
    if self\.debug

    # Don't complain if tests don't hit defensive assertion code:
    raise AssertionError
    raise NotImplementedError

    # Don't complain if non-runnable code isn't run:
    if 0:
    if __name__ == .__main__.:

ignore_errors = True

omit =
    # omit anything in a .local directory anywhere
    # omit everything in /usr
    # omit third-party code
    # omit test files


08/30/2021, 9:45 PM
Huh! Is it specifically slow when using this config file or when doing test coverage in general? If you use coverage with this config deleted, what happens?


08/30/2021, 9:46 PM
When using
! which is kind of bizarre to me. Once I rename that file to something else (so it's not used when pants runs coverage) it's blazing fast
My hypothesis is that using this file might disable/override some parallel running of tests that Pants does? but I am not sure how I can test that.


08/30/2021, 9:53 PM
Weird! Maybe it's the branch=True? I recommend trying to iteratively add back your config to find the offending line. Start with an empty coveragerc (outside of the relative files line), and see if perf is good. Then add one more line, and test. And so on until you find the offending line


08/30/2021, 9:53 PM
I tried setting that to False but it's the same
Looks like adding
makes it a bit slower, but having the section
(even when the section is left empty) will make it much slower
Ah looks like I was mistaken! they're about the same speed... just that without .coveragerc it was using cache πŸ™ˆ
❗ 1


08/30/2021, 10:02 PM
Good deduction. Thanks for clarifying!
βœ… 2
Also, good to know you're getting good value from the cache.
😁 2


08/30/2021, 10:02 PM
too good to be true lol
🀣 1


08/30/2021, 10:04 PM
Brings whole new meaning to "10x programmer"
🀣 1


08/31/2021, 5:01 AM
Hmm, maybe it would be good to emphasize when the cache is used, perhaps as a summary at the end, like: β€œCache hits: 42 out of 512 task results came from cache. β€œ Realize that you might want to break this down a little bit too.. Per goal or subsystem or or something.. unsure what granularities we can get..
βž• 1
βœ… 1