Help us test build times in Meteor 1.3

Hi everyone,

In the upcoming Meteor 1.3 with ES6 modules support, we added an additional pass on source files to search for import or require statements. That adds some overhead to the build process. We want to know exact numbers from real apps in production. Can you help? It will just take a few moments.

If your app is running on Meteor 1.2.1, please run:

time meteor build /tmp/build --debug --server localhost

three times and show the numbers that you get.

Then run:

meteor update --release 1.3-modules-beta.0

in your app directory and once it’s done run the same command above three times and show the numbers that you get.

It’s worth pointing out that Meteor 1.3 will contain an improvement to rebuild times, so even if initial build times are slightly slower it may end up being a net improvement to productivity. Also curious to hear other people’s opinions on this.

Thanks!

6 Likes

With Wekan (both git branches are available on the GitHub repository for reproduction):

➜  wekan git:(devel) time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost  57,10s user 5,65s system 100% cpu 1:02,32 total

➜  wekan git:(meteor-1.3) time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost  95,88s user 5,83s system 104% cpu 1:37,02 total

My computer configuration is here.

A project without Browserify, the only build packages are CoffeeScript

1.2.1
meteor build /tmp/build --debug --server localhost 25.94s user 6.94s system 110% cpu 29.842 total
meteor build /tmp/build --debug --server localhost 26.03s user 6.78s system 109% cpu 29.986 total
meteor build /tmp/build --debug --server localhost 25.69s user 6.42s system 111% cpu 28.784 total

1.3 beta
meteor build /tmp/build --debug --server localhost 31.55s user 8.73s system 109% cpu 36.854 total
meteor build /tmp/build --debug --server localhost 30.15s user 6.92s system 108% cpu 34.228 total
meteor build /tmp/build --debug --server localhost 30.34s user 6.94s system 109% cpu 34.039 total

To be honest I care way more about the reload time in development mode than the build time, but I haven’t seen an improvement on that side either.

6 Likes

The rebuild time improvement is not in 1.3-modules-beta.0. It will be out in the next 1.3 beta release.

But you can try 1.2.2-faster-rebuilds.0 which is 1.2.1 with https://github.com/meteor/meteor/pull/5747 merged in. Have you tried that?

3 Likes

Ah ok, I just tried it and the 3.5s taken by the constraints solver are indeed lowered to 60ms if there isn’t any package change. That’s a good improvement!

5 Likes

Great! How long do the other steps of rebuilding your app take?

Can you please run this three times for each release? Sometimes there are outliers that skew the average.

I joined the complete METEOR_PROFILE build time schedule (on Meteor 1.2.1) here. Yes, I missed the 3× instruction, I will run this test again tomorrow.

Here you go:

updated to Meteor 1.2.1.
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m20.200s, user  1m38.559s, sys 0m26.449s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m2.173s, user  1m39.402s, sys 0m21.429s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m28.220s, user  1m37.076s, sys 0m22.828s
MacBook-Pro: $ meteor update --release 1.3-modules-beta.0

updated to Meteor 1.3-modules-beta.0.
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  3m40.861s, user  2m41.678s, sys 0m26.131s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m14.200s, user  1m51.901s, sys 0m22.365s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m17.379s, user  1m50.597s, sys 0m21.434s
MacBook-Pro: $ meteor update --release 1.2.2-faster-rebuilds.0

updated to Meteor 1.2.2-faster-rebuilds.0.
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m53.602s, user  1m51.330s, sys 0m26.152s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m31.845s, user  1m44.702s, sys 0m21.355s
MacBook-Pro: $ time meteor build /tmp/build --debug --server localhost
real  2m32.371s, user  1m40.638s, sys 0m20.755s

For anyone who wants to test all three versions and complete all 9 test runs in one go with a one-liner (although a long one LOL) you can copy and paste this whole beast onto your terminal in one go within your project root folder and hit enter.

echo "Paste the contents of this file over at https://forums.meteor.com/t/help-us-test-build-times-in-meteor-1-3/15031" >> .build-times.txt && \
cat .meteor/release >> .build-times.txt && \
meteor reset > /dev/null 2>&1 && \
for i in {1..3}; do /usr/bin/time --append --output=.build-times.txt meteor build /tmp/build --debug --server localhost ; done && \
meteor reset > /dev/null 2>&1 && \
meteor update --release 1.3-modules-beta.0 > /dev/null 2>&1 && \
cat .meteor/release >> .build-times.txt && \
for i in {1..3}; do /usr/bin/time --append --output=.build-times.txt meteor build /tmp/build --debug --server localhost ; done && \
meteor reset > /dev/null 2>&1 && \
meteor update --release 1.2.2-faster-rebuilds.0 > /dev/null 2>&1 && \
cat .meteor/release >> .build-times.txt && \
for i in {1..3}; do /usr/bin/time --append --output=.build-times.txt meteor build /tmp/build --debug --server localhost ; done && \
meteor update --release 1.2.1 > /dev/null 2>&1 && \
meteor reset > /dev/null 2>&1 && \
echo "done testing"

Then go for a coffee and come back in around 20-30 minutes. If you see “done testing” on the command prompt, it is all dandy. Head over to your project root folder to find the file named .build-times.txt and paste the contents over here.

The script will have reverted your app back to 1.2.1 (assuming it started out like that) so you can pick up development where you’ve left off.

On my Ubuntu laptop with i7 CPU, 4GB Ram and an SSD drive, I got the following results:

METEOR@1.2.1
120.85user 9.19system 2:20.63elapsed 92%CPU (0avgtext+0avgdata 516996maxresident)k
310240inputs+545752outputs (3major+700194minor)pagefaults 0swaps
65.64user 7.50system 1:21.70elapsed 89%CPU (0avgtext+0avgdata 419768maxresident)k
418688inputs+311240outputs (32major+185628minor)pagefaults 0swaps
64.26user 6.95system 1:16.60elapsed 92%CPU (0avgtext+0avgdata 417700maxresident)k
264944inputs+313040outputs (15major+187362minor)pagefaults 0swaps

METEOR@1.3-modules-beta.0
149.67user 9.90system 2:49.05elapsed 94%CPU (0avgtext+0avgdata 563240maxresident)k
282784inputs+431048outputs (0major+693500minor)pagefaults 0swaps
81.54user 8.22system 1:40.48elapsed 89%CPU (0avgtext+0avgdata 444244maxresident)k
475744inputs+352368outputs (112major+205042minor)pagefaults 0swaps
78.04user 7.20system 1:22.51elapsed 103%CPU (0avgtext+0avgdata 444512maxresident)k
158296inputs+337368outputs (101major+205076minor)pagefaults 0swaps

METEOR@1.2.2-faster-rebuilds.0
120.42user 7.68system 2:16.25elapsed 94%CPU (0avgtext+0avgdata 517416maxresident)k
155880inputs+433072outputs (0major+651741minor)pagefaults 0swaps
68.26user 6.62system 1:14.73elapsed 100%CPU (0avgtext+0avgdata 414112maxresident)k
87440inputs+320232outputs (91major+188879minor)pagefaults 0swaps
69.56user 6.59system 1:11.99elapsed 105%CPU (0avgtext+0avgdata 411872maxresident)k
5584inputs+314864outputs (3major+196819minor)pagefaults 0swaps

PS: I’m not a bash expert so this can be improved in many ways and perhaps even incorporated into meteor command as a flag to the build option. Also, I made this on a ubuntu box, so especially the location of the /usr/bin/time command may be different on different systems.

2 Likes

time meteor build /tmp/build --debug --server localhost

real 0m27.419s user 0m27.420s sys 0m3.056s
real 0m27.410s user 0m27.380s sys 0m2.768s
real 0m27.750s user 0m27.748s sys 0m2.796s
time meteor build /tmp/build --debug --server localhost

real 0m53.484s user 0m53.564s sys 0m3.216s
real 0m31.929s user 0m31.752s sys 0m3.316s
real 0m32.731s user 0m32.664s sys 0m3.216s

@avital

The rebuild time improvement is not in 1.3-modules-beta.0. It will be out in the next 1.3 beta release.

is this release out yet? I’m confused the thread asks to help but it’s not available yet. Also unclear how your release packaging works. there’s a 1.3-release branch here:

but:

> meteor update --release release-1.3 
Meteor release-1.3: unknown release.          

I’ll try

 meteor update --release 1.2.2-faster-rebuilds.0

1.3-modules-beta.0 is the name of the release, not release-1.3. You can try it out by running meteor update --release 1.3-modules-beta.0 in your app. (This was explained in the original post)

We’ll get 1.3-modules-beta.1 out today with the rebuild time improvement and other bug fixes.

release-1.3 is the name of a branch in Git, which can’t be used directly from an installed version of Meteor. To run the cutting edge of that branch, you need to follow the slow start instructions.

Hope this clarifies some things.

1 Like

Hello Avi,

the upgrade from 1.2.1 to release 1.3-modules-beta.0 crashes our build: one of our packages contains folders with JavaScript files that should not be included in the package. The package.js does not refer to these files, yet the new build seems to pick up on them and crashes:

dirkstevens$ time meteor build /tmp/build --debug --server localhost
Errors prevented bundling:
While computing assigned variables:
/packages/wonder-analysis/build/src-js/columnar.part.js: Unexpected token (3:0)
/packages/wonder-analysis/build/src-js/exports.js: Unexpected token (25:1)

While computing assigned variables:
/packages/wonder-visuals/build/lib-js/var.js: Unexpected token (3:0)

While computing assigned variables:
/packages/wonder-analysis/build/src-js/columnar.part.js: Unexpected token (3:0)
/packages/wonder-analysis/build/src-js/exports.js: Unexpected token (25:1)

While computing assigned variables:
/packages/wonder-visuals/build/lib-js/var.js: Unexpected token (3:0)

Tested on Mac OS X Yosemite.

Dirk

Then go for a coffee and come back

Always good instruction :slight_smile:

1 Like

Hi Dirk,

Yes, you’re right. The new build system in 1.3 parses all .js files within your package directory. Is this a package you built or a community package? What is the purpose of those .js files that don’t parse?

Avital

Hi Avital, I would like to redo the build time test for Wekan, but I’m still blocked by https://github.com/meteor/meteor/issues/5871.

Hello Avi,

These files are part of a private package and are in essence “logic.readable.js” and “logic.minified.js”. Most of the time we include the “minified.js”, but when we encounter a problem we include the “readable.js” in the package.

The true source is legacy HX (Haxe) code that is converted to JS. Our minification is done with Google Closure compiler.

Dirk

Hi Dirk,

Do you mind filing this as a GitHub issue with a simple reproduction?

Thanks,
Avital.