Meteor 1.4.2 beta - solid 2x improvement in rebuild speed!


#1

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 :slight_smile:. 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:

meteor update --release 1.4.2-beta.6

And here’s a pull request on GitHub for 1.4.2: https://github.com/meteor/meteor/pull/7668


Issues with isobuild following Project migration from v1.2.1 to v1.3/1.4
:satellite: TRANSMISSION #15: Community Involvement, 1.4.2, GraphQL subscriptions, and Grapher
#2

Nice! Any regressions we need to be aware of?

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.


#3

I’m not aware of any regressions. If anything, the app feels faster on localhost, but that may be due to placebo effect :wink:


#4

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?


#5

Here you have detailed performance logs:

1.4.0.1: http://pastebin.com/25NTX364
1.4.2-beta.6: http://pastebin.com/2xY7UNca

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 :slight_smile:.


#6

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).


#7

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).


#8

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 :slight_smile:


#9

Cool! Then I must have been reading it wrong. 3-4 seconds is fine, I thought I read 10s +


#10

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.


#11

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 :slight_smile:


#12

I saw on GitHub that some people reported 3x gains, so your mileage may vary, my tests are just one data point :slight_smile:


#13

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.


#14

Just checked out beta.7. It is now taking 3s for a reload before it was 20+


#15

Try METEOR_OFFLINE_CATALOG=1 meteor


#16

Oh man i cannot wait to have it released ! We are going to be so much more productive !!!
Thanks MDG and all community to work on that !


#17

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.


#18

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):


Building / cold start

Meteor 1.4.1: 40 seconds
Meteor 1.4.2: 24 seconds

Server code change - rebuilding

Meteor 1.4.1: 3.5 seconds
Meteor 1.4.2: 1.8 seconds

Client code change - rebuilding

Meteor 1.4.1: 8.5 seconds
Meteor 1.4.2: 1.7 second (5x improvement!)


Overall, I like what I see :slight_smile:

PS. What I would like even more is speeding up meteor build time, especially (but not limited to) when iOS and Android are added as platforms.


Using /imports/ui slows down development compared to /client/...?
#19

Any help on this issue?

meteor update --release 1.4.2-beta.13
/Users/alexander/.meteor/packages/meteor-tool/.1.4.1_2.fpzmec++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/isopackets/ddp/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:165
throw error;
^

Error: ENOENT: no such file or directory, open '/private/var/folders/pm/c9jbj_3s2zjfvk5rjk7byxgw0000gn/T/mt-1qhlcbs/os.json’
at Error (native)

Gettting it on all betas for meteor 1.4.2

Thanks a lot!
java99


#20

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 !