Our builds are too slow(4-6 mins) even rebuilds are taking more than 2 mins.
Slowest Nodes (totalTime => 5% ) | Total (avg)
Package /assets/vendor.js (8) | 107129ms (13391 ms)
broccoli-persistent-filter:StyleLinter (5) | 92582ms (18516 ms)
Pod Templates (8) | 49938ms (6242 ms)
SassCompiler (29) | 25469ms (878 ms)
Our application is pretty large with close to 50MB code base including all node-modules.
I want to know any possibility to skip rebuilds of other nodes like vendor, SassCompiler if changes are only in our app folder. For example, even there is no change in vendor still it is rebuilding, same for SassCompiler.
If someone can guide, it will be really helpful. I tried broccoli-viz, but it is not highly helpful, because of large number of nodes.
Note: I’m newbie to Ember.
Unfortunately this is all too common in larger apps. There was a thread not too long ago about reducing build time so you could start there. Disabling build-time linting can be a big help…
You could also try out Embroider, Ember’s next-gen build system which (at least eventually, possibly now) might be faster. It’s still under active development and some addons may still break with it but it could be worth a shot to try it out.
In addition to all the good suggestions above (I would definitely stop linting inside the build, it’s just as good to lint inside your editor and CI), one other ideas:
On ember-cli 3.15+ there is a new rebuild optimization that’s still behind a feature flag as its gets stabilized. You can try it by setting the environment variable
BROCCOLI_ENABLED_MEMOIZE=true. It can help a lot.
Thanks for suggestion. Disabled linting it save around 25 seconds each build.
Regarding Embroider, installed and ran ember build got error something like this
BroccoliMergeTrees: Expected Broccoli node, got [Funnel],[I18nBroccoli],[Creator: Object./assets/assets-fingerprint.js] for inputNodes
I just tried will try with debugger in build and get some more clarity, before that I just want to update about same.
Thanks for timely help
Thanks for suggestion.
Sadly, we are still in 3.4.4
I would not have told anybody to try embroider solely to solve their build performance problem. It’s premature. Use it if you’re interested in spending time helping contribute bug reports and/or fixes that will help us stabilize it for everyone. If you aren’t interested in spending that time, it’s not stable enough yet.
Also, it is likely to be faster, even right now, for some apps. But it’s also entirely possible it’s slower for some situations, just because it hasn’t had the same years of optimization that the more tried-and-true build pipeline has. And the biggest speed benefits won’t come until we can start shipping addons in the new proposed format, so less things need the compatibility layer.
Sure, will spend some time to understand. Will try to contribute by atleast being tester if not developer.
Larger apps with more addons may need sometime to adopt new things. Lets me check further, if any help required will comeback.