Below are results of my unscientific benchmark of (re)build speeds of the newest Meteor version 1.4.2-beta.6. The tests were performed on a production app I’m working on, with about 15k SLOCs. The app has 190 packages according to versions file and uses ES6 modules, Blaze and a LESS preprocessor. From my observation it seems that while cold start build time actually regressed (~17% slower), rebuild times are significantly faster, in every test I could see 50% decrease (2x faster).
The test was performed with METEOR_PROFILE=100 setting and I always recorded two times reported for two major build steps: ProjectContext prepareProjectForBuild and (Re)Build App. For the sake of completeness I’ve ran some of the tests twice to see how caching alters the result. So here are the results:
While the build times are still not ideal (webpack is still way faster), they went down from almost painful to manageable, which is a step in good direction . Congrats to all involved in this release! Hopefully by the time the final version releases the benefits will be the same or even better (I would especially appreciate speeding up the cold start build speed).
Btw, to install the current beta all you have to do is to issue this command:
I have this old app from Meteor 1.2 being revived with lots of local packages (being shared across two apps) and they kind of both need to be running at the same time so a ctrl+s invoking a rebuild on both apps. It re-builds in around 1 minute!
If there’s no regression (compared to 1.4), I’m willing to do the upgrade, which will require some refactoring.
One thing I’m really excited about is building something into the tool that warns people when specific build plugins take a very long time, since this can often be the culprit of very long rebuild times.
@M4v3R do you have an idea of what parts of the compilation process are taking up that time?
In the first phase - ProjectContext prepareProjectForBuild - it seems that _resolveConstraints (particularly generate constraints and sqlite query) takes huge amount of time (264 ms => 18,267 ms) in 1.4.2 compared to 1.4.0.1. Note that I did run the app after upgrading, then killed it, purged disk cache and ran it again, reporting that last run in the benchmark.
The second phase is actually a bit faster on 1.4.2 beta, so that part is good .
One update. running the app now, without purging disk caches, resulted in faster initial build, faster than with 1.4.0.1 (5 seconds and 18 seconds respectively for both phases).
I’m not trying to be negative here, but even if these % improvements are so great. Wouldn’t it all be a lost cause if it still takes 10s or more for every rebuild? People will just start moving to Webpack and alikes anyway? (10s is a lot… especially when you’re writing html).
Currently it takes 2-5 seconds for a rebuild for my not-so-small app (depending on whether I change shared server & client code or only templates/stylesheets). So 3-4 seconds on average is not that bad
Well, if build time drops to 2-3 sec, it will be just a bit longer than my approximate webpack rebuilds. (1.5 sec)
Maintaining webpack along with app is thing I wouldn’t want to do.
True and agreed. I’m just worried that the relative gain (e.g. x2) is too low. In my case some rebuilds take more than 20 seconds, so x2 would mean 10s. And that’s with a ssd even. But I’ll try it first, before worrying
I just saw one thing which would cut my rebuild times by 80%:
The “Checking for missing packages / versions” routine.
Seriously, that one takes way longer than the actual build, at least for me. I also don’t think that packages go missing / are updated since the last build from one minute ago.
Which reminds me: What exactly is the rationale to put all UI stuff into the /imports-folder and not somewhere into client? Because the latter only necessitates a reload on the client (and not all of the time). The former triggers a full-server rebuild which takes way longer.
I’m not seeing the big advantage here and it’s also not documented anywhere.
Note that ‘client’ and ‘imports’ may be combined. Anything under ANY imports directory is lazy loaded. Anything under ANY client directory should only be loaded on the client (same thing for server directories). The directory doesn’t have to be at the top level.
So, theoretically, you’re welcome to use ‘imports/client’ or ‘client/imports’ for the same effects.
I’ve measured the speed improvements again on beta 13, this time on the todos app. Here are the results (in all cases I did all actions twice and recorded 2nd result):
For me, most of the time the build tool is taking care of a client side change.
So i have gone from “much too long”, to quasi instantaneous.
Cold start is still long, but we can live with it.
Great work Ben !
. Congrats to all involved in this release! Hopefully by the time the final version releases the benefits will be the same or even better (I would especially appreciate speeding up the cold start build speed).
.