OS: OSx El Capitan
RAM: 8GB
Time: ~17 seconds
Meteor Version: v1.2.0.1
File Count: ~50 files
Build Plugins: LESS
In a fresh project, with only 10 files, the build time is approx. 12 seconds…
P.S. Both of the times mentioned, are rebuid times. Initial builds are even slower.
1 Like
As a baseline I tried creating a new project with no packages, and added 50 js files that had console.log in them.
- 2.3ghz i7 2012 rMBP
- 4.38 seconds
- v1.2
- 53 files
- No packages
1 Like
Yes without a baseline project, what’s the point of making these comparisons? Some people share OS version but not whether they are on 5400 RPM drive or SSD.
How about forking a large project like https://github.com/wekan/wekan so everyone is compiling the same thing?
Otherwise some of you might be compiling a project with 10 lines of CSS and three packages, while others are running a project with several thousand lines of CSS and several dozen packages, etc.
3 Likes
More useful: can anyone share the difference in speed when compiling the same project on different machines? i.e. iMac with SSD vs no-SSD
We are thinking to upgrade our iMacs to Apple Mac Pro with the hope of reducing our build time.
Seems Apples has a very liberal return policy during the holidays, so if we get around to buying one I’ll report our results here.
1 Like
Yea having a baseline project would prob. help too. I was most interested in the overall time people had to wait for a reload. In general it’s way too high. Some of compile languages reload faster 
(with the exception of iOS, that’s a slog).
My SSD benchmarks around 400-500 Mbps (the new ones are much faster) and the ‘fairly empty’ project above with 1line of code and 53 files was ~4 seconds.
This was mostly sparked by my surprise to see that the new ES6 modules didn’t utilize Webpack… but perhaps the new imports will help speed up reloads (haven’t heard back from the PR comment yet).
At least it’s fairly easy to use as a 3rd party add-on. I have one more app that I need to convert yet but am waiting for more test coverage first.
cloned wekan, ran meteor update, updated layouts.jade to: img(src="{{pathFor '/wekan-logo.png'}}" alt="WekanX")
~20 secs
Win7x64
i7@2.3
16GB RAM
SSD
~45 secs
Win10x64
i3@2.2
8GB RAM
Non-SSD
Having experienced hot reload changing the page almost instantly makes those 20/45 secs even more painful.
1 Like
Can you describe how you are measuring the time? Would be good to ensure we are measuring i the same way
Put a digital clock on the side, add an X to the file, when the secs turn back to 0 I click the save button, then wait for the page to start and finish reloading .
It’s good enough for a ballpark number.
should we standardize on a browser too? Chrome 46?
Latest chrome but it doesn’t really matter since we’re talking about very rough numbers and it’s just to see a ballpark of what people are getting.
I know what you mean, and you’re probably right. For me, the main reason for posting, was to get MDG’s attention that build times are way (way) too high. At least for me, in multiple situations (as fresh a project as can be).
I’ve mentioned this multiple times, in multiple places (here, github) but whenever I do, MDG doesn’t seem to feel the need to respond. If I were the only one, I would get that. But threads like these seem to indicate I’m not alone…
I can’t keep taking the normal Meteor builds seriously if even the tiniest change will take 20 seconds to build. Then what do all the other adjustments in the build and/or packages matter? It’s unuseable?
2 Likes
I wouldn’t say it’s unuseable; we put several Meteor apps into production each year. But sure, could be faster.
We upgraded our machines to recent iMacs with fast processors, extra RAM and fast SSD drives. So if you’re not on fast hardware you can start with that.
It’s unuseable only in the sense that what takes the meteor build 15 seconds (quite important part of the framework), in regards to the webpack build that seems to take 2. If you calculate that times 100 rebuilds a day, adds up 
Forever on large e-commerce project.
We are trying to stay as far away from running whole application as we can.
BDD or TDD to the rescue, package testing is quite fast if you include test-only lib package with just basic meteor internals and few more packages you use in that given package.
1 Like
I just purchased a faster computer and wanted to share the results in case anyone was wondering how much of a speed jump they’ll get if they upgraded.
late 2015 retina iMac 27"
4ghz i7
256gb SSD (PCI express)
8GB RAM
With this hardware it’s almost bearable.
App1 Before
11.5 sec reload
App1 After:
4.7 sec reload
App2 Before (webpack app)
1.4 sec reload
App2 After:
0.76 sec reload (avg several times)
Wekan
6.8 sec reload
1 Like
Nice, But I think the absolute speed isn’t the real issue, it’s Meteor’s build speed vs what Webpack can do with the same result and the same code base. Altough I can’t speek for all the details that I might be missing, but that difference (10x?) makes the Meteor build look silly
1 Like
I totally agree. Absolute times will vary on every machine. Although having product X and Y times will help devs know what they can expect with an upgrade.
I think paying someone to upgrade the codebase to webpack might be cheaper 
One thing to note on upgrading, upgrading to 1.3 modules first is a much much easier process because currently it allows you to retain the load order and switch a modules one by one. Going cold turkey to webpack means everything is broken until at the least, all of the modules for that route is resolved.
@slava showed me the meteor_profile option, which allows the build tools to provide detailed informations regarding where the time is spent:
$ METEOR_PROFILE=1 meteor
I’ve done the test with Wekan and the result is here, it takes roughly 12s to reload the app on my computer — yes @SkinnyGeek1010, I’m jealous
5 Likes
Hmmmm, my app used to reload within 5 seconds, but now it’s taking 154 seconds!!
I ran with $ METEOR_PROFILE = 1 meteor and get some large numbers here:
files.chmod: 44981.2
files.lstat: 35888.8
files.readdir: 22903.2
files.stat: 15513.5
files.readFile: 10728.8
files.writeFile: 6595.1
files.mkdir: 3475.4
files.read: 3171.5
files.rename: 2994.9
Anyone know what’s going on??