I’ve been experimenting with build times for Meteor and have come to the conclusion that for large or the smallest/blank newly created apps are about 20 seconds (a large production app with cached bundled assets takes 20-22 seconds, a blank application with cached bundled assets takes 17-20 seconds).
I believe the biggest reason for this is Meteor is 1.) not parallelizing and 2) doing to much.
On 1.) node and meteor are limited by the event loop so asset compilation happens in series, rather then utilizing multiple cores, this slows things down a lot. I’m not sure where the resistance is to compile each plugin in it’s own thread via a thread pool. I’m sure some things must be done in series when collecting assets.
On 2.) Doing to much, for one example after a build and exiting Meteor, the build process begins entirely again rather than determining if anything in the application has actually changed, so the whole process begins again (however starting
node .meteor/local/build/main.js is nearly instant). Since Meteor is limited by the event loop and not IO, we should consider CPU the more available resource I believe. As example I tested on a machine w/e an NVMe that can read & write around 2GB/s, more than the entire assets of a project.
Additionally but less investigated Meteor minifies in development, or at the very least you can see something happening in when run with
METEOR_PROFILE. Which seems odd.
Results were compared from a Macbook Retina & a Dell R820 (4*2.7GHz - 64 threads, 256GB, 2GB/s nvme SSD), results we’re comparable between both devices which both run at 2.7GHz, and boost to 3.3GHz.
Now, however for rebuild times we do an excellent job, and things can be only a 1-3 seconds, which is great!
With all this said, how can we improve meteors build process and where can a developer start. Because it feels like the build code is bit of a maze, some higher level documentation would be nice to have here.
Related Feature Request: https://github.com/meteor/meteor-feature-requests/issues/312