Upgrade RAM or CPU for better build times?


#1

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)


#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/.


#3

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.


#4

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


#5

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.


#6

Thank you guys very much!


#7

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.


#8

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.

see:

ember help build


#9

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.