Chore: Apply memoization to config creation within glob utils #9944
Conversation
|
|
lib/util/glob-util.js
Outdated
| @@ -8,7 +8,8 @@ | |||
| // Requirements | |||
| //------------------------------------------------------------------------------ | |||
|
|
|||
| const fs = require("fs"), | |||
| const _ = require("lodash"), | |||
There was a problem hiding this comment.
We prefer just using lodash variable in the rest of the codebase, would you mind switching that up here? Thanks!
lib/util/glob-util.js
Outdated
| @@ -88,6 +89,18 @@ function resolveFileGlobPatterns(patterns, options) { | |||
| return patterns.filter(p => p.length).map(processPathExtensions); | |||
| } | |||
|
|
|||
| const dotfilesPattern = /(?:(?:^\.)|(?:[/\\]\.))[^/\\.].*/; | |||
|
|
|||
| const memoGetIgnorePaths = _.memoize( | |||
There was a problem hiding this comment.
I'm not convinced this function (or the one below) needs a "memo" prefix, but I won't insist on a change here.
|
@platinumazure changes made! Left the commit out for clarity for now, will rebase them in later. |
|
Thanks for the PR! To clarify, does this just memoize the creation of the |
|
@not-an-aardvark that is correct. To your point, I'm not sure how some of the editor integrations happen, but if they're long-running, and if it's possible that this options object gets mutated upstream, we might provide an old response due to a false positive on referential equality. I'm imagining this is not the case though. |
|
As far as I remember, there are a few projects that use long-running eslint through APIs. I think VSC uses eslint-server which keeps eslint process running in memory. There's also eslint_d project that does the same. So if this might result in memory leak for long-running instances, this might cause problems. |
|
Alright, I've updated -- now the memozation only runs for the duration of the Theoretically the code is improved and could be merged as such with minimal risk, or I can continue looking into this. |
eslint-deprecated
bot
added
the
archived due to age
What is the purpose of this pull request? (put an "X" next to item)
[ ] Documentation update
[ ] Bug fix (template)
[ ] New rule (template)
[ ] Changes an existing rule (template)
[ ] Add autofixing to a rule
[ ] Add a CLI option
[ ] Add something to the core
[x] Other, please explain:
What changes did you make? (Give an overview)
I attempted a brief review of
eslintwith performance in mind and I found (just) a few quick wins.Running the repo's
linttask with--debugI first noticed that the ignore file processing occurred multiple times in a row without significant changes.In this branch, the above ignored-paths steps only occur once.
Anecdotally, I have been seeing pretty consistent gains in the
perfexecution, but even bumping the runs up a lot, it's simply too noisy to post and stand behind. I can attempt some more work on this if desired.That all said, what I have done is prevent a new object creation (due to its cost and loss of referential equality) when it's unnecessary.
Then once that has been done, since I noticed these executions are more likely to be similar than different, I included two small, memoized functions to help create this object, and get a new instance of the
IgnoredPathsclass.Is there anything you'd like reviewers to focus on?
I need help testing my assumptions:
IgnoredPathsclass. I feel pretty good about the immediate consumeraddFile, but I don't necessarily have enough context for the rest.