-
Notifications
You must be signed in to change notification settings - Fork 11
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
Significant performance degredation #197
Milestone
Comments
Closed
3 tasks
Bisect (predictably) points to e84c746 |
spenserblack
added a commit
that referenced
this issue
Sep 27, 2023
This drastically improves performance by no longer cloning the index state, which only needs to be set once. Resolves #197
spenserblack
added a commit
that referenced
this issue
Sep 27, 2023
This drastically improves performance by no longer cloning the index state, which only needs to be set once. Resolves #197
spenserblack
added a commit
that referenced
this issue
Sep 27, 2023
This drastically improves performance by no longer cloning the entire repository index state. Resolves #197
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Turns out
gengo
is once again much slower. Given the changes in #191, the most likely culprit is theGit
source. Originally blobs were read and analyzed in parallel. Now they're only analyzed in parallel.Edit: The biggest time-consumer seems to be calling
file_source.overrides
🤔Ideas
FileSource
returns a iterator over tuples of filenames and file contents. Perhaps the iterator should only yield filenames, and provide a methodget_contents
that takes that filename. That could possibly be easier to parallelize and boost performance.filename()
andcontents()
methods that takeSelf::Iter::Item
and return the filename and contents.analyze_blob
function and return results.overrides
methodanalyze_blob
callsself.file_source.overrides
analyze
passesanalyze_blob
toself.file_sources.handle
The text was updated successfully, but these errors were encountered: