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

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

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

2 Likes

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:

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

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.

1 Like

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:

1 Like

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

2 Likes

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.

1 Like

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

4 Likes

Try METEOR_OFFLINE_CATALOG=1 meteor

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 !

1 Like

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.

4 Likes

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.

6 Likes

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

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 !

2 Likes

Temporary fix:

Here’s how I did workaround this bug (which is basically a CDN issue) without modyfing hosts file:

METEOR_WAREHOUSE_URLBASE=https://d3fm2vapipm3k9.cloudfront.net meteor update --release 1.4.2-beta.13
1 Like

Awesome!

Could we somehow script this into a test? Would be pretty useful… :slight_smile:

1 Like

@M4v3R & @wursttheke

Solved it. thanks a lot!

yet now it does not startup :frowning:

modules.js?hash=6a1d620…:35850 Uncaught TypeError: _extends is not a function (anonymous function) @ modules.js?hash=6a1d620…:35850(anonymous function) @ modules.js?hash=6a1d620…:35804meteorInstall.node_modules.react-bootstrap.lib.Alert.js @ modules.js?hash=6a1d620…:36643fileEvaluate @ install.js:153require @ install.js:82meteorInstall.node_modules.react-bootstrap.lib.index.js @ modules.js?hash=6a1d620…:35158fileEvaluate @ install.js:153require @ install.js:82Mp.import @ modules.js?hash=6a1d620…:442meteorInstall.client._App.AppHeader.jsx @ app.js?hash=7cca9c4…:8052fileEvaluate @ install.js:153require @ install.js:82Mp.import @ modules.js?hash=6a1d620…:442meteorInstall.client._App.AuthenticatedApp.jsx @ app.js?hash=7cca9c4…:8331fileEvaluate @ install.js:153require @ install.js:82Mp.import @ modules.js?hash=6a1d620…:442meteorInstall.client._App.Routes.jsx @ app.js?hash=7cca9c4…:8656fileEvaluate @ install.js:153require @ install.js:82Mp.import @ modules.js?hash=6a1d620…:442meteorInstall.client._App.App.jsx @ app.js?hash=7cca9c4…:7917fileEvaluate @ install.js:153require @ install.js:82(anonymous function) @ app.js?hash=7cca9c4…:13559