We have an ambitiously large ember-cli app (our pods folder is 3.4 MB for 1,101 items) running on the bleeding(ish) edge version of everything:
Ember : 2.0.2
Ember Data : 2.0.0
and are really sad at how long it takes our app to recompile every time a file changes. For example, if I make a change to a single template, I have a frustrating 28 seconds until the page loads…
Needless to say, developing w/ these ~30 second waits is causing us to lose our minds. Anyone experience something similar or have ideas on how to speed up our compilations? I’m surprised since the goal of this framework is large apps that no one else is complaining about these waits…
I’m on a super small project compared to yours but it takes ~5-10 secs to build. It was so annoying I first ditched the idea of using live reload and now I’m not using ember serve at all. While developing, I serve the app via python -m SimpleHTTPServer and run ember build as needed.
ember-cli build times are super slow and I won’t consider using it on any projects of significant size.
Interesting - with that approach, how often do you need to build? If I change a template, doesn’t a precompile have to happen before I can see any updates in the bowser? We also ditched live-reload a while back…
It takes the same time unfortunately. The good thing is, I can save a few files before I run the build. With live reload, it would spin up the build task as soon as the first file has changed which essentially means I’ll just sit there waiting for build to complete before my second file is picked up.
@rytis, right, that’s why we disabled live-reload (ember server --live-reload=false) it doesn’t sound like there is any advantage to running a manual ember build every time… So I’m starting to think that ember is good for ambitiously large apps but ember-cli chokes at even small ones
One of the reasons for slow build times is the fact that it does a full rebuild regardless of which file has changed. Touching a CSS file would trigger a full rebuild. It feels like I’m missing some trivial setting in build config file.
Yeah, I too feel like I’m missing something obvious. Not to mention, similarly (and more difficult to fix) touching one file reruns 2k tests (this is a solved problem in the rspec world).
I think what would be great is if there was a verbose mode to understand why it’s taking so long. We don’t even have that many sass files for the SassCompiler to take 2.3s every time.
In addition, I don’t even understand why, for example, sass compiler runs every time a javascript file is changed. It should be smarter than that…
@jthoburn - Can you quantify ‘comparably large’? Do you use pods? Can you put your build output like I did in here? Can you include your package.json so we can compare versions?
Your boasting 10x faster than we have with the same app size; I’d love to see some more details as it sounds like either your app isn’t as large as you say it is or there’s a difference in specs that might mean we can see some speed improvements by adjusting some things on our end (we, too, have ‘Watchman + SSD’)
@coladarci are you running Ember CLI 1.13.8 or master? I’d suggest giving master a try if you are not as a number of great speed improvements have been merged in the past few weeks. They have not seen a general release yet but at least this way you’d be able to tell whether your issues have already been resolved.
If you are still seeing really long build times on master I would suggest trying to replicate it with the Ember CLI stress app and submit a PR to help with debugging.
Your setup and problem seems similar to ours, but at a slightly larger scale. For us, the problem was not so much ember-cli as it was the Mac itself.
Once we got past the natural ‘ulimit’ problems that prevented the build from actually succeeding (solved by upgrading OSX or by manually raising the ulimit) we found that the file read access was being shared between node (no watchman, here) and the Mac indexing service. As node_modules, bower_components, tmp and dist were rebuilt, Mac was doing its level best to re-index for us - entirely unnecessary. The issue was exacerbated for me because I use Webstorm as my IDE, and it maintains its own file index cache.
I don’t know how the results scale, but it dropped my build from ~13 seconds to ~10. I didn’t dig any farther because I’m not far removed from some serious Java projects, where we were looking at 5-7 minutes per build/deploy…13 seconds seemed like a miracle!
