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