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??