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.
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
Cache option for searchers #43
Cache option for searchers #43
Changes from 3 commits
0c124d7
0ebf699
148b677
5ba50ab
2090b6c
5c4a141
b073423
d9721f4
de7ad2a
5c6e3ac
abe9528
f2a4440
92a8c61
903e561
f2b1a1a
cad8f7a
d0fbdfe
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If lilconfig is configured with multiple
searchPlaces
, this code will lookup for the same cache entry for each search place. In the case of Prettier, 14 different searchPlaces are passed.Since
Map.prototype.has
is very efficient, it shouldn't make a big difference performance-wise. But it be ideal to avoid this.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.
I am using
searchPath
as a cache key, notfilepath
. On each iterationsearchPath
is the directory where we expect the config to be, not the full path to the config file. This keeps the code simpler and we will have less entries in the cache as a result. Example values from a loop iteration:searchPath
->/foo/bar/baz
filepath
->/foo/bar/baz/prettier.config.js
I agree that the naming is rather confusing. I haven't came up with a better names.
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.
Thanks for the clarification. I think my comment is still valid, here is a concrete example:
In the above example,
getSearchItems
would generate the following entries:{ searchPath: './foo', filepath: './foo/package.json' }
{ searchPath: './foo', filepath: './foo/.prettierrc' }
{ searchPath: './foo', filepath: './foo/.prettierrc.json' }
{ searchPath: './', filepath: './package.json' }
{ searchPath: './', filepath: './.prettierrc' }
{ searchPath: './', filepath: './.prettierrc.json' }
Correct me if I am wrong but with the for loop iterating over the entries generated by
getSearchItems
, when cache is enabled, it appears to me that this code will do:searchCache.get('./foo')
searchCache.get('./')
IMO, it's not a big deal performance-wise since the
has
check on aMap
is not very expensive. But ideally, the code should do 1 lookup for eachsearchpath
in the search cache.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.
Thanks for expanding on this. I've switched the look up for two nested loops. No more unnecessary look ups