Repository navigation
should _get_file_reporter get maxsize=None? #2182
Description
quote from discord:
i'm trying to understand something:
get_analysis_to_report calls coverage._get_file_reporters(morfs) which creates a PythonFileReporter per file (calling parse_source)
then it calls coverage._analyze(morf) per file, which calls _get_file_reporter(morf) one more time, but _get_file_reporter has maxsize=1, so on a multi-file report every call is a cache miss, creating a second PythonFileReporter with a second parse_source
based on commit history, i think you meant to not only set _analyze to maxsize=None, but also _get_file_reporter as well, but missed it
Activity
nedbat commentedon May 30, 2026
_analyzeand_get_file_reporterboth have a cache size of 1. In a multi-file report, each is visited in turn and won't be needed again once we move onto the next file. But the code structure is such that these functions might be called more than once while processing each file. So they have a cache of 1 to avoid parsing a file twice while reporting on it.KRRT7 commentedon May 30, 2026
I see, so the idea is to avoid parsing files multiple times during reporting, in that case.
wouldn't reusing the ast object from the statement/arc analysis and threading It thru phystokens.source_token_lines and find_soft_key_lines also have the same purpose?
nedbat commentedon May 30, 2026
It could be that there are other ways to save time. "Threading thru" often conflicts with "keep things modular," so the current code might be the right compromise. I didn't try to avoid the second calls to the functions. I added the 1-element cache to keep those redundant calls from being a problem.
KRRT7 commentedon May 30, 2026
in this case, main...KRRT7:coveragepy:perf/share-ast it doesn't look too bad, and it eliminates 2 redundant ast.parse() calls per file per report.