Is r.js dependency tracing significantly slower since v2.1.16? Or is it just me?
I noticed a dramatic increase in build time in r.js versions 2.1.16 / 2.1.17 compared to 2.1.15 and earlier. The extra time seems to be wasted during "Trace dependencies for ...".
Mine build.js
looks something like this:
({
baseUrl: 'some/path/here',
mainConfigFile: 'some/path/here',
dir: 'some/path/here',
modules: [
{
name: "base"
},
{
name: "specific",
exclude: ["base"]
}
],
findNestedDependencies: true,
removeCombined: true,
skipDirOptimize: true,
optimize: "none"
})
Run this build using node.js on windows environment. Both base
and specific
have a decent (but not absurd) number of nested dependencies ( base
referenced internally in specific
, and therefore excluded). At 2.1.15 this build will take ± 2 seconds on my system; 2.1.16 / 2.1.17 takes ± 8 seconds . (note that all dodges are disabled, so this is not a factor)
I'm including this one build.js
for reference, but I don't think it's really my settings that are causing the slowdown. I've tried many (simple) scenarios and they all look much slower when tracking 2.1.16 / 2.1.17 dependencies.
Who also has this happening? Or is it just me? I'm sure as my project grows, this 4x increase in build time will start to annoy me exponentially, so please advice :-)
source to share
I have the same problem on Linux with findNestedDependencies: true
. The issue is reported here https://github.com/jrburke/r.js/issues/850
Below is the following release information http://requirejs.org/docs/download.html . This is the most likely cause of the problem.
2.1.16
Notable changes in the r.js optimizer:
Esprima 2.0 is used by the optimizer when parsing modules for dependencies. This allows for some ES6 functionality. Whatever Esprima 2.0 understands is what is supported (when working in xpcshell, Reflect.parse is still used).
source to share
you can try the latest snapshot r.js . jrburke says this change improves significantly.
from github comment :
[PR] # 900 just landed on a change that seems to really cut down on the time spent in the parsing steps. If people who have had slow build times want to try from the last master snapshot & hellip;
source to share