Large resolve.extensions make build process slower significantly

[tai2]

Do you want to request a feature or report a bug?

bug
(or feature, not sure)

What is the current behavior?

I have an webpack config which contains many elements in resolve.extensions (13 extentions).
This file was generated by webpacker on default configuration.

This increases build time significantly compared to fewer extentions.
To make matters worse, it causes heap allocation error in my real project then I cannot build the app.

An example of build time measurements of a project:

number of resolve.extentions	build time(ms)
2	10264
3	11645
4	17079
5	26940
6	42766
7	70409
8	85172
9	121312
10	191606
11	255123
12	270727
13	492126

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/tai2/webpack-build-time-increase-example

What is the expected behavior?

Reasonable build time regardlress of resolve.extenions.
O(1) or O(N) algorithm if it's possible.

If this is a feature request, what is motivation or use case for changing the behavior?

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

Node.js: v8.1.2
webpack: 3.0.0
OS: Darwin Kernel Version 16.6.0
CPU: Core i7 3.1GHz
RAM: 16GB

[pksjce]

Hey @tai2 , I tried your sample repository to reproduce the issue.
I got the following results more or less with

• with webpack 3.0.0 + 13 extensions

• with webpack 3.0.0 + 2 extensions

With `webpack 3.1.0 also I got similar result with a difference of 2-3 seconds between the two runs.
Can I do something else to reproduce your issue?

[tai2]

@pksjce Thanks for trying it. What's your node.js version?

[tai2]

I tried it on another ubuntu environment, the issue was not reproduced. 🤔 🤔 🤔

[pksjce]

I'm using v7.2.0. Will that make a difference? I also tried this directly on webpack's resolver which is https://github.com/webpack/enhanced-resolve . I tried it with 2-13 extensions and found similar perf differences of couple of seconds only.

[tai2]

I asked few people to run the sample program.
No one reproduced the issue except for me.
hummm

[hiroppy]

Node's version is 8.1.0 and webpack is 3.1.0.
I used Mac.

2 extensions

> NODE_ENV=development webpack --config webpack/dev.js

Hash: cc5736328da18ab1eab0
Version: webpack 3.1.0
Time: 1869ms
    Asset     Size  Chunks                    Chunk Names
bundle.js  2.97 MB       0  [emitted]  [big]  main
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {0} [built]
[./src/index.jsx] ./src/index.jsx 171 bytes {0} [built]
   [0] multi babel-polyfill ./src/index.jsx 40 bytes {0} [built]
    + 479 hidden modules

13 extensions

> NODE_ENV=development webpack --config webpack/dev.js

Hash: cc5736328da18ab1eab0
Version: webpack 3.1.0
Time: 3855ms
    Asset     Size  Chunks                    Chunk Names
bundle.js  2.97 MB       0  [emitted]  [big]  main
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 509 bytes {0} [built]
[./src/index.jsx] ./src/index.jsx 171 bytes {0} [built]
   [0] multi babel-polyfill ./src/index.jsx 40 bytes {0} [built]
    + 479 hidden modules
npm run build:dev  4.04s user 0.57s system 83% cpu 5.498 total

Is there a possibility of your machine problem?

[tai2]

I got it.

You can reproduce the problem on the environment below.

1. Use nodebrew. Not reproduced with Homebrew's node.
2. Run cd ~/ && ln -s .nodebrew/current/lib/node_modules node_modules
3. Run example code

I had a symbolic link node_modules in user home which points to nodebrews's global installation directory. This contained npm itself.

I don't understand why this caused performance problem.
And I don't know when and why this symbolic link was generated.

But this issue is probably my specific problem and rarely occurs to others.
So I close this issue.