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.755sFor 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
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.01.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 
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.
$ time meteor build /tmp/build --debug --server localhost
real 1m17.487s
user 0m51.284s
sys 0m15.120s
$ time meteor build /tmp/build --debug --server localhost
real 1m1.387s
user 0m49.824s
sys 0m13.728s
$ time meteor build /tmp/build --debug --server localhost
real 1m0.071s
user 0m48.096s
sys 0m14.292s
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 51.27s user 13.88s system 115% cpu 56.460 total
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 50.90s user 13.68s system 116% cpu 55.396 total
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 51.20s user 13.81s system 116% cpu 55.800 total
1.3
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 165.25s user 17.15s system 106% cpu 2:51.67 total
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 67.61s user 14.68s system 113% cpu 1:12.58 total
❯ time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 68.25s user 15.02s system 114% cpu 1:12.98 total
I’ve also noticed that beta4 is much slower than the previous betas, no hard evidence, but just from working with it. Were you using beta4, the latest 1.3 release?
Yes, it was the latest release (beta4)
We have a simple meteor project, that imports a private npm package that contains most of our shared components.
The private npm package exposes a bundle.js file that is built with webpack, in the main property.
The size of this bundle.js file significantly impacts Meteor’s build time, even if it’s already compressed. Is this expected?
For example, if the bundle.js file is 400kb, Meteor’s build time looks like (on beta4, beta5 has stylus issues for us):
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 26.55s user 5.13s system 104% cpu 30.232 total
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 24.33s user 4.86s system 109% cpu 26.711 total
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 23.79s user 4.66s system 112% cpu 25.311 total
Fully loaded, the package is 2.6mb (uncompressed), and meteor’s build time doubles (if we compress the bundle.js file, times don’t change):
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 51.93s user 8.56s system 104% cpu 57.715 total
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 55.48s user 9.23s system 103% cpu 1:02.35 total
time meteor build /tmp/build --debug --server localhost
meteor build /tmp/build --debug --server localhost 54.21s user 9.04s system 103% cpu 1:01.25 total
Rebuild times are killing our productivity, and we were hoping that we could improve build times by separating most of our code into an npm package that’s managed by webpack, which meteor would import as any other npm package. The code inside the actual meteor project is minimal - it mostly just imports components from the compiled npm package.
1 Like
Here are my times with the newest METEOR@1.3-modules-beta.5
My installed packages:
accounts-password
blaze-html-templates
ecmascript
email
jquery
jsx
mobile-experience
mongo
random
session
standard-minifiers
tracker
underscore
agnito:raphael
aldeed:collection2
aldeed:simple-schema
dburles:collection-helpers
flowkey:bowser
harrison:papa-parse
juliancwirko:s-alert
juliancwirko:s-alert-flip
kadira:flow-router
maximum:computed-fields
meteorhacks:kadira
meteorhacks:kadira-profiler
meteorhacks:search-source
meteorhacks:subs-manager
meteorhacks:zones
mrt:jquery-easing
richsilv:owl-carousel
ultimatejs:tracker-react
I have the following installed with npm:
"material-ui": "^0.14.3",
"moment": "^2.11.1",
"nouislider": "^8.2.1",
"react": "^0.14.6",
"react-addons-css-transition-group": "^0.14.6",
"react-dom": "^0.14.6",
"react-komposer": "^1.3.0",
"react-mounter": "^1.0.0",
"react-tap-event-plugin": "^0.2.1"
Initial build time with no files in the entire project:
real 0m35.736s
user 0m29.775s
sys 0m3.304s
Pretty good. When I add a single (small) client/FlowRouter.jsx file, build times stay roughly the same. Adding a console.log to a route and testing file modifications, subsequent reloads are roughly 7 seconds after file saves. Not bad.
But as soon as I import three other component/JSX files (located in client/imports directory) to the FlowRouter.jsx file, build times are immediately exacerbated.
Initial load time:
real 1m2.826s
user 0m51.577s
sys 0m6.625s
Now, making the exact same change to the FlowRouter.jsx file as before (changing a console.log line), reload times are now 25 seconds.
There is something seriously wrong here. This is a project with 4 files.
I tried disabling all modules, adding each one back in and testing times, however this didn’t change build times at all. I did manage to port my entire medium-sized app to 1.3, however it was a lot of blind coding, then sipping my coffee for a few minutes between builds. It’s not possible to develop within it’s current state.
I’m very excited about the future though! Meteor 1.3 is a pleasure to develop in (I’m imagining 7 second page reloads or less here 
). The new import/exports functionality and npm integration is fantastic.
Update: I forgot to mention what build times are with the current app on Meteor 1.2. Here is initial build:
real 0m26.592s
user 0m19.694s
sys 0m3.154s
And modifications take roughly 17 seconds to reload. However, this is with all of the Meteor-specific packages and no npm (react, material-ui, etc.).
7 seconds is still very long compared to something like webpack where it’s 2-3 seconds.
I really hope 1.3 brings some serious improvements because my builds clock at 15-20 seconds and I still have to wait for the page to reload after that.