contentprovider: cache last newlines lookup #722
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I wanted to introduce another call to newlines.atOffset for the purpose of scoring. I was worried about doubling the calls to this so introduced a tiny (but hopefully effective) performance optimization. Essentially we often look up multiple times on the same line, but then the return of atOffset shouldn't change. So we introduce a tiny cache for this. We could do even more and if we are not on the same line, use the last computed index to restrict which side of the nls.locs we look at. However, there are no direct benchmarks for this and I haven't seen it in profiles before. So just doing this minor optimization for fun. Test Plan: go test
|
Alright turns out I don't need this. I am gonna close this out, since unless I see this appearing in a profile it isn't worth the extra complexity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I wanted to introduce another call to newlines.atOffset for the purpose of scoring. I was worried about doubling the calls to this so introduced a tiny (but hopefully effective) performance optimization.
Essentially we often look up multiple times on the same line, but then the return of atOffset shouldn't change. So we introduce a tiny cache for this.
We could do even more and if we are not on the same line, use the last computed index to restrict which side of the nls.locs we look at. However, there are no direct benchmarks for this and I haven't seen it in profiles before. So just doing this minor optimization for fun.
Test Plan: go test