Upgrade ram OR cpu for faster builds?


I’m due for a new machine, and am wondering which components (RAM/CPU/SSD) are most important for optimizing ember-cli build+rebuild times.

If anyone is willing to time a build+rebuild of the Ghost-Admin project@v1.22.5, and share your RAM/CPU/SSD specs, that would be awesome! 1.22.5 is the latest tagged version of Ghost, which is using ember 3.1.1 https://github.com/TryGhost/Ghost-Admin/archive/1.22.5.zip

On my 2013 Macbook Air (4GB ram/1.3GHz Intel Core i5/128GB ssd/macOS High Sierra 10.12.6) –– ember s took 2 minutes and 31 seconds to show the green Build successful text in the console, with a 24 second rebuild time (added // on a blank line in app/app.js to trigger rebuild) (Ran this on node: 6.12.2)


I don’t know which hardware is the most important but here are some stats to compare anyway.

MacBook Pro 13-inch, 2015 (2.7ghz i5 + 16gb ram)

  1. ember s: 83964ms
  2. rebuild: 4501ms
  3. restart ember s 26382ms

You could also try comparing machines with https://v8.github.io/web-tooling-benchmark/.


Hey @DevinRhode2 :wave: I work on Ghost-Admin daily so I’ll share my machine/experience :smile:

Current machine is Late 2016 MacBook Pro 13" with the 2.9Ghz i5 and 16GB ram.

Development builds typically take 25-30s but can sometimes be 60-190s. I haven’t been able to tie anything specific to why the times vary so wildly. I can see 28s on a completely fresh build and sometimes 120s on a warm build although normally it’s on the lower end of the scale. 30sec is about average in day to day development.

Rebuilds are usually between 4 and 8s. Again not a lot of consistency so difficult to objectively measure.

I upgraded to this machine from a 2012 MacBook Pro with 2.9Ghz i7 and 8GB of RAM and to be honest I didn’t notice much difference in build times when I did. As long as you’ve got a decent SSD and you’re not over-taxing your RAM then you should be good :+1:

Node itself has it’s own maximum RAM limit so there’s a ceiling where more RAM won’t make much difference. You’re better off taking other workloads into consideration because they can impact how much free RAM you have whilst the build process is running. That said, my advice is always to fit as much RAM as you can (within affordability) into a machine, especially if the machine doesn’t have upgradeable parts.


For comparison’s sake here are my numbers using the fresh zip package. Times are using Node 8.10.0. I waited for mds_stores to finish indexing the extracted zip and node_modules dir but it’s been 2 weeks since I last restarted my laptop so system processes and long-running apps are using a fair bit of memory:

1st run…
Build: 56,527ms
Rebuild: 5,576ms

2nd run (“warm” build)…
Build: 27,646ms
Rebuild: 4,517ms


My bet is that the first thing to optimize is making sure you have a good fast SSD. Which is pretty much a given on any modern mac.

The second is raw single-core speed (more cores won’t help much, builds are mostly not parallelized).

I measured on my mid-2014 macbook pro with 3Ghz core i7, and got 69sec first cold build with 4 second rebuild. Despite being an older machine with an older iteration of chips, the raw clockspeed keeps it competitive.


Thank you guys very much!


So I looked into optimizing read/write speed and have some tidbits to report back!

-Trim Enabler boosted my read/write from ~400/130 to 440/170 (in MB/s)

While larger SSD’s are faster, it looks like the speed boost in newer MBP models is “not very much” for most users… although I wonder how a bump in MB/s translates to build time in ember. (https://forums.macrumors.com/threads/2016-mbps-ssd-speed-difference.2017527/)

Looks like 2000+MB/s for read and write is pretty typical for a new machine these days

Also learned that SSDs slow down as they fill up, so I could probably further optimize read/write speed by offloading archives I have to external drives.


For development, I would make sure you are building with the -w flag on which speeds up the refresh cycle by not rebuilding the whole app more than once.


ember help build


For development, instead of ember build -w I would recommend ember serve, which does the building and watching but also runs the development http server.


By offloading un-necessary files to an external hard drive, going from 20gb free on my 128gb drive, to now 72gb free, I increased my write speed to about 205MB/s. (from 170)


A Dell XPS Tower upgraded to be an ABSOLUTE BEAST will run you 1400… we’re talking the best processor on the market, 4.7GHz (plus can probably overclock because it’s a desktop). Then you can get 32GB of ram (200 dollars, included in the 1400!) and create a virtual ram disk for even faster disk read/write speeds. SSH in from any cheap-o laptop, run ubuntu on it, and setup a shared network drive/folder somehow, and then edit this on your laptop… for someone that’s always working in proximity to their wifi network, this may very well be one of the best possible setups…

MacBook Pro, with best processor is only 3.5GHz, and about $2500, but moving up to 4.7GHz for about a grand less, AND getting the 32GB ram for creating a virtual ram disk… yeah I think this might be the way to go

Details on the 1400 xps tower upgrades: Starting with the cheapest XPS tower with the i7 ($1049) upgrade the processor from 4.6GHz to 4.7GHz ($100), upgrade the RAM to 32GB ($200), upgrade to a small 256GB ssd ($30), upgrade the wifi ($25)

Really the base configuration should also work really well for just a plain dev server (About 30% faster processor for half the price)


I have compiled a list of tweaks that improve build time drastically. It includes stats: https://emberjs-developer.quora.com/How-to-make-Ember-js-CLI-ember-s-32-times-faster


In general here are some tips for improving speeds.

  1. Develop on Unix or Mac (sadly Windows Filesystems are not as watcher or file change friendly this goes for Webpack and Parcel builds too from my experience)
  2. Use and SSD M.2 drives or PCIe based SSDs are big improvements over regular SSDs for this since there’s lower latency and faster read/write speeds. The MacBook and MacBookPro use PCIe drives since the Retina based models. Even new MacBook Airs use slower SSDs even though they are still soldered to the main board. If you are looking at a PC many of the pro line laptops and desktops use M.2 drives or have a M.2 expansion slot.
  3. Single Core/Thread Speed - Like @ef4 mentioned right now Ember CLI and broccoli are mostly single threaded. Newer processors with similar core speeds will give slightly better results (and use less power) but in general the single core speed is the limiting factor now.
  4. Room on drive. Especially on the Mac. All drives slow down on writes with a fuller disk. Macs also slow down more as the disk fills up because there’s background cleanup and auto swap space being allocated

That said, Broccoli 2.0 will help with a lot of these issues.

  1. Broccoli 2.0 introduces in-memory tmp adapters, this means that there will be less file watching, writing, and reading if the swap or RAM storage adapter is used. This will improve speeds and reduce read/writes to disk (ssd lifecycles rejoice)
  2. M.2 drives are still faster but with fewer reads/writes, then this read/write speed becomes less of a bottleneck (although still gives general wins)
  3. Plans for the future of Ember CLI and Broccoli seem to be pointing to more parallelization so more cores can improve future performance. Depending on what you are running in the background, more cores/threads can drastically improve performance. If chrome, OS, Slack, Ember CLI, and your IDE share a 5.2 GHz dual core you’d probably get better results with an 8 or 16 thread core running at 3.2GHz since each program get’s a full set of processing power rather than sharing.
  4. Drive room still comes into play although same with 1&2, read/write bottlenecks or other drive activity shouldn’t have as much of an impact.