module: significantly improve loader performance #26970

BridgeAR · 2019-03-28T23:29:14Z

This is a significant performance boost for require in case a module is loaded more than once. This came up as a botteneck for @jasnell and @mcollina as far as I know.

It is now possible to use require lazily without sacrificing much performance. Loading files with relative paths is now up to 4-5x faster when loaded frequently!

Loading relative or absolute paths now has the same performance profile. The native startup will likely not be impacted.

I introduced a new cache which sits on top of the former main cache and caches the filename of already loaded modules. This is then used to check for lazy require calls and for identical require calls from different files in the same directory.

Refs: #25362

Benchmark: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/311/

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

nodejs-github-bot · 2019-03-28T23:29:17Z

@BridgeAR Sadly, an error occurred when I tried to trigger a build. :(

nodejs-github-bot · 2019-03-28T23:30:34Z

CI: https://ci.nodejs.org/job/node-test-pull-request/22000/

BridgeAR · 2019-03-28T23:50:46Z

@nodejs/modules PTAL

guybedford

I guess the only concern here is cases like the following where you have say x.json:

require('./x'); // resolves x.json
fs.writeFileSync('./x.js', 'module.exports = "new"');
require('./x'); // should resolve x.js

as surely the above case would get the JSON file again instead of the x.js contents?

No one will actually do that though, so this is fine, but in theory that is a break from semantics right?

Similarly if the relative resolution was running through package.json "main" or a directory index check, these would also be cached, with similar risks to the above right?

If this is done for package resolutions eg require('y') then we're basically just caching the resolver, which may not be intended. The restriction of the cache to the local directory sort of restricts the timeframe to make it feel like its correct, when in theory you could load a subpath of a package later. For example say require('pkg/index.js') loads require('dep') where require('pkg/index2.js') is then loaded much later might expect a different value for require('dep'). At least according to the current semantics that would be valid for require('dep') to be something else if the package.json changed. Again, no one would do that, but it's still not quite the same.

So for those sorts of reasons it worries me I must admit... it doesn't feel like this performance comes completely for free, although it certainly is close enough to free to feel like it could be worthwhile.

lib/internal/modules/cjs/loader.js

guybedford · 2019-03-29T00:25:24Z

Correction - my mentions to package.json changes above don't apply due to the package.json cache, but everything else from a statting perspective does apply (extensions checks, node_modules lookups).

guybedford

Thinking about this more, the edge cases are so well designed in this approach that they will never be hit. There are some liberties, but they seem to work out. The perf definitely seems worth it. Sorry I can't be more enthusiastic, but I've been stuck on semantics too long.

BridgeAR · 2019-03-29T00:57:23Z

@guybedford

everything else from a statting perspective does apply (extensions checks, node_modules lookups)

We also have the stat cache and that should cause the already resolved file from the first require call to be loaded.

the edge cases are so well designed in this approach that they will never be hit.

Thanks, that was my intention.

nodejs-github-bot · 2019-03-29T01:03:06Z

CI: https://ci.nodejs.org/job/node-test-pull-request/22003/

guybedford · 2019-03-29T01:44:18Z

We also have the stat cache and that should cause the already resolved file from the first require call to be loaded.

Ok, so if the example was rather:

node_modules/dep does exist
lib/node_modules/dep does not exist

let dep = require('dep');
fs.mkdirSync('./lib/node_modules/dep');
fs.writeFileSync('./lib/node_modules/dep/index.js');
exports.reloadDep = function () {
  dep = require('dep');
}
setTimeout(() => exports.reloadDep());

where there was an expectation that lib/node_modules/dep could be written and then reloaded as above. So lazy require cache I guess as you say.

lib/internal/modules/cjs/loader.js

jdalton · 2019-03-29T14:04:53Z

lib/internal/modules/cjs/loader.js

-  var cachedModule = Module._cache[filename];
-  if (cachedModule) {
+  const cachedModule = Module._cache[filename];
+  if (cachedModule !== undefined) {
    updateChildren(parent, cachedModule, true);
    return cachedModule.exports;
  }


Could this be done at the Module._resolveFilename level?
A cache key could be something like

cacheKey = request + "\0" + dirPath + "\0" + (isMain ? "1" : "")

That would not be beneficial as far as I can tell. I would also rather not move any parts around since the loader is highly monkey patched and every subtle change can cause side-effects.

isMain should not have any impact on the key as it's only about the very first require call and that is not required for the cache key.

Add more benchmark options to properly verify the gains. This makes sure the benchmark also tests requiring the same module again instead of only loading each module only once.

Moving `try / catch` into separate functions is not necessary anymore due to V8 optimizations.

This adds the `path` property to the module object. It contains the current directory as path. That is necessary to add an extra caching layer. It also makes sure the `id` uses a default in case it's not set. Otherwise the `path.dirname(id)` command could fail.

This adds an extra modules caching layer that operates on the parent's `path` property and the current require argument. That together can be used as unique identifier to speed up loading the same module more than once. It is a cache on top of the current modules cache. It has the nice feature that this cache does not only work in the same file but it works for the whole current directory. So if the same file is loaded in any other file from the same directory, it will also hit this cache instead of having to resolve the file again. To keep it backwards compatible with the old modules cache, it detects invalidation of that cache.

BridgeAR · 2019-03-31T11:00:02Z

Rebased due to conflicts.

nodejs-github-bot · 2019-03-31T11:00:15Z

CI: https://ci.nodejs.org/job/node-test-pull-request/22056/

nodejs-github-bot · 2019-03-31T14:44:43Z

CI: https://ci.nodejs.org/job/node-test-pull-request/22067/

mcollina

LGTM on green CITGM

BridgeAR · 2019-04-03T12:24:28Z

CITGM https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1796/ ✔️

PR-URL: nodejs#26970 Refs: nodejs#25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]>

Moving `try / catch` into separate functions is not necessary anymore due to V8 optimizations. PR-URL: nodejs#26970 Refs: nodejs#25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]>

This adds the `path` property to the module object. It contains the current directory as path. That is necessary to add an extra caching layer. It also makes sure the `id` uses a default in case it's not set. Otherwise the `path.dirname(id)` command could fail. PR-URL: nodejs#26970 Refs: nodejs#25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]>

This adds an extra modules caching layer that operates on the parent's `path` property and the current require argument. That together can be used as unique identifier to speed up loading the same module more than once. It is a cache on top of the current modules cache. It has the nice feature that this cache does not only work in the same file but it works for the whole current directory. So if the same file is loaded in any other file from the same directory, it will also hit this cache instead of having to resolve the file again. To keep it backwards compatible with the old modules cache, it detects invalidation of that cache. PR-URL: nodejs#26970 Refs: nodejs#25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]>

BridgeAR · 2019-04-04T12:19:49Z

Thanks for the reviews.

Landed in 3b04496...0f190a5 🎉

A recent commit broke test-benchmark-module. This fixes it. Culprit is nodejs#26970.

PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

Add more benchmark options to properly verify the gains. This makes sure the benchmark also tests requiring the same module again instead of only loading each module only once. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

Moving `try / catch` into separate functions is not necessary anymore due to V8 optimizations. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

This adds the `path` property to the module object. It contains the current directory as path. That is necessary to add an extra caching layer. It also makes sure the `id` uses a default in case it's not set. Otherwise the `path.dirname(id)` command could fail. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

This adds an extra modules caching layer that operates on the parent's `path` property and the current require argument. That together can be used as unique identifier to speed up loading the same module more than once. It is a cache on top of the current modules cache. It has the nice feature that this cache does not only work in the same file but it works for the whole current directory. So if the same file is loaded in any other file from the same directory, it will also hit this cache instead of having to resolve the file again. To keep it backwards compatible with the old modules cache, it detects invalidation of that cache. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

Add more benchmark options to properly verify the gains. This makes sure the benchmark also tests requiring the same module again instead of only loading each module only once. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

Moving `try / catch` into separate functions is not necessary anymore due to V8 optimizations. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

This adds the `path` property to the module object. It contains the current directory as path. That is necessary to add an extra caching layer. It also makes sure the `id` uses a default in case it's not set. Otherwise the `path.dirname(id)` command could fail. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

This adds an extra modules caching layer that operates on the parent's `path` property and the current require argument. That together can be used as unique identifier to speed up loading the same module more than once. It is a cache on top of the current modules cache. It has the nice feature that this cache does not only work in the same file but it works for the whole current directory. So if the same file is loaded in any other file from the same directory, it will also hit this cache instead of having to resolve the file again. To keep it backwards compatible with the old modules cache, it detects invalidation of that cache. PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

Refs: nodejs#26970 Fixes: nodejs#33270

Refs: #26970 Fixes: #33270 PR-URL: #33323 Reviewed-By: Anna Henningsen <[email protected]>

BridgeAR added module Issues and PRs related to the module subsystem. benchmark Issues and PRs related to the benchmark subsystem. labels Mar 28, 2019

guybedford reviewed Mar 29, 2019

View reviewed changes

lib/internal/modules/cjs/loader.js Outdated Show resolved Hide resolved

lib/internal/modules/cjs/loader.js Outdated Show resolved Hide resolved

guybedford approved these changes Mar 29, 2019

View reviewed changes

BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 29, 2019

mscdex reviewed Mar 29, 2019

View reviewed changes

lib/internal/modules/cjs/loader.js Show resolved Hide resolved

jdalton reviewed Mar 29, 2019

View reviewed changes

BridgeAR added 5 commits March 31, 2019 12:57

benchmark: add new module loading benchmarks

b5683e7

benchmark: improve module-loader benchmark

faa0518

Add more benchmark options to properly verify the gains. This makes sure the benchmark also tests requiring the same module again instead of only loading each module only once.

module: inline try catch

50e2414

Moving `try / catch` into separate functions is not necessary anymore due to V8 optimizations.

BridgeAR force-pushed the improve-loader-performance branch from c7c034d to 9137c56 Compare March 31, 2019 10:59

joyeecheung mentioned this pull request Apr 2, 2019

CI failures: 20190330-20190402 nodejs/reliability#22

Closed

BridgeAR requested review from jasnell, mcollina and devsnek April 3, 2019 12:13

mcollina approved these changes Apr 3, 2019

View reviewed changes

BridgeAR added a commit to BridgeAR/node that referenced this pull request Apr 4, 2019

benchmark: add new module loading benchmarks

a8b69d4

PR-URL: nodejs#26970 Refs: nodejs#25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]>

BridgeAR closed this Apr 4, 2019

Trott added a commit to Trott/io.js that referenced this pull request Apr 4, 2019

test: fix test-benchmark-module

ab04470

A recent commit broke test-benchmark-module. This fixes it. Culprit is nodejs#26970.

Trott mentioned this pull request Apr 4, 2019

test: fix test-benchmark-module #27094

Closed

2 tasks

BethGriggs pushed a commit that referenced this pull request Apr 9, 2019

benchmark: add new module loading benchmarks

09d6dfb

PR-URL: #26970 Refs: #25362 Reviewed-By: Guy Bedford <[email protected]> Reviewed-By: Matteo Collina <[email protected]> Signed-off-by: Beth Griggs <[email protected]>

BethGriggs mentioned this pull request Apr 9, 2019

v11.14.0 proposal #27163

Merged

BridgeAR added the performance Issues and PRs related to the performance of Node.js. label May 8, 2019

guybedford mentioned this pull request Oct 31, 2019

module: add cache of request and filename to optimize require perf #21404

Closed

4 tasks

BridgeAR mentioned this pull request Dec 20, 2019

for ... of replacing for(;;) in library networking code? #31024

Closed

BridgeAR deleted the improve-loader-performance branch January 20, 2020 11:59

aduh95 added a commit to aduh95/node that referenced this pull request May 9, 2020

doc: document module.path

997f01b

Refs: nodejs#26970 Fixes: nodejs#33270

aduh95 mentioned this pull request May 9, 2020

doc: document module.path #33323

Closed

3 tasks

addaleax pushed a commit that referenced this pull request May 19, 2020

doc: document module.path

a82001a

Refs: #26970 Fixes: #33270 PR-URL: #33323 Reviewed-By: Anna Henningsen <[email protected]>

codebytere pushed a commit that referenced this pull request May 21, 2020

doc: document module.path

f52b56c

Refs: #26970 Fixes: #33270 PR-URL: #33323 Reviewed-By: Anna Henningsen <[email protected]>

codebytere pushed a commit that referenced this pull request Jun 7, 2020

doc: document module.path

6dbcd0a

Refs: #26970 Fixes: #33270 PR-URL: #33323 Reviewed-By: Anna Henningsen <[email protected]>

codebytere pushed a commit that referenced this pull request Jun 9, 2020

doc: document module.path

98a7026

Refs: #26970 Fixes: #33270 PR-URL: #33323 Reviewed-By: Anna Henningsen <[email protected]>

baby636 mentioned this pull request Jul 12, 2023

[Snyk] Security upgrade gatsby from 2.24.27 to 2.24.64 baby636/node#104

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

module: significantly improve loader performance #26970

module: significantly improve loader performance #26970

BridgeAR commented Mar 28, 2019 •

edited

Loading

nodejs-github-bot commented Mar 28, 2019

nodejs-github-bot commented Mar 28, 2019

BridgeAR commented Mar 28, 2019

guybedford left a comment

guybedford commented Mar 29, 2019

guybedford left a comment

BridgeAR commented Mar 29, 2019

nodejs-github-bot commented Mar 29, 2019

guybedford commented Mar 29, 2019 •

edited

Loading

jdalton Mar 29, 2019

BridgeAR Mar 31, 2019

BridgeAR commented Mar 31, 2019

nodejs-github-bot commented Mar 31, 2019

nodejs-github-bot commented Mar 31, 2019

mcollina left a comment

BridgeAR commented Apr 3, 2019 •

edited

Loading

BridgeAR commented Apr 4, 2019

module: significantly improve loader performance #26970

module: significantly improve loader performance #26970

Conversation

BridgeAR commented Mar 28, 2019 • edited Loading

Checklist

nodejs-github-bot commented Mar 28, 2019

nodejs-github-bot commented Mar 28, 2019

BridgeAR commented Mar 28, 2019

guybedford left a comment

Choose a reason for hiding this comment

guybedford commented Mar 29, 2019

guybedford left a comment

Choose a reason for hiding this comment

BridgeAR commented Mar 29, 2019

nodejs-github-bot commented Mar 29, 2019

guybedford commented Mar 29, 2019 • edited Loading

jdalton Mar 29, 2019

Choose a reason for hiding this comment

BridgeAR Mar 31, 2019

Choose a reason for hiding this comment

BridgeAR commented Mar 31, 2019

nodejs-github-bot commented Mar 31, 2019

nodejs-github-bot commented Mar 31, 2019

mcollina left a comment

Choose a reason for hiding this comment

BridgeAR commented Apr 3, 2019 • edited Loading

BridgeAR commented Apr 4, 2019

BridgeAR commented Mar 28, 2019 •

edited

Loading

guybedford commented Mar 29, 2019 •

edited

Loading

BridgeAR commented Apr 3, 2019 •

edited

Loading