FS caching improvements #375
Merged
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
When using `cacheDirectory=true`, the `findCacheDir` module is repeatedly called, and it does some synchronous filesystem calls under the hood. However, since `findCacheDir` is more or less a pure function, it's probably safe to call it only once during process lifetime.
Codecov Report
@@ Coverage Diff @@
## master #375 +/- ##
==========================================
+ Coverage 81.04% 81.87% +0.82%
==========================================
Files 6 6
Lines 153 160 +7
Branches 33 35 +2
==========================================
+ Hits 124 131 +7
Misses 13 13
Partials 16 16
Continue to review full report at Codecov.
|
danez
reviewed
Feb 12, 2017
src/resolve-rc.js
Outdated
|
|
||
| return find(loc, rel); | ||
| return (cache[cacheKey] = find(loc, rel)); |
There was a problem hiding this comment.
For readability here can you use a template string and reverse the logic?
if (!cacheKey in cache) {
cache[cacheKey] = ...
}
return cache[cacheKey];
There was a problem hiding this comment.
Done deal. I wasn't sure whether template strings were allowed by the local code style. :)
|
Thanks, that looks all awesome. Did you check if the build gets faster with this? |
|
I measured things a little (somewhat unscientifically, of course, since this is on my MBP and there's other IO and processing noise). The "babel-core" patch mentioned is babel/babel#5292 . The TL;DR is "yes, it does have an effect 😸 " Performance measurements
Sync IO tracesOutput summarized by https://github.com/akx/summarize-sync-io All stockPatched babel-loaderPatched babel-loader and babel-core |
|
Thank you |
danez
pushed a commit
that referenced
this pull request
Feb 12, 2017
* Instantiate default cache directory lazily, and only once When using `cacheDirectory=true`, the `findCacheDir` module is repeatedly called, and it does some synchronous filesystem calls under the hood. However, since `findCacheDir` is more or less a pure function, it's probably safe to call it only once during process lifetime. * Cache resolve-rc results
This was referenced Mar 19, 2018
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.
While tracking down the reason for some build slowness with
--trace-sync-io, I found a couple file system hotspots that could use some caching.cacheDirectory=true,findCacheDiris repeatedly called, and it does some synchronous calls under the hood. HoweverfindCacheDiris more or less a pure function, so it's probably safe to call it once during process lifetime.resolve-rchas some caches for singleexistsandreadoperations, but there's still some more time that can be shaved off by simply memoizing the entireresolve-rcfunction.These should not be breaking changes, unless
.babelrcfiles are created in intermediate directories during process lifetime, which sounds very unlikely.