The build process for my meteor application is super slow, but only when I do a meteor reset. Can someone please suggest some simple heuristics to troubleshoot? What should I be looking at, (a) cpu usage? (b) publications?
I don’t understand why it is slow after meteor reset but not otherwise? Advice appreciated.
It’s slow after a Meteor reset because that operation deletes the cache from previous builds.
Without the cache, the build has to start from scratch which is much slower, so that part is normal.
How long are the builds taking? For cold start (after reset), warm start (normal start) and hot reload (rebuild during development)?
So using your terminology, (a) cold start - 5 mins, (b) warm start - 1 minute, bit less maybe © hot reload - very quick, does not impact my development at all [as in, seconds, these seem normal for meteor].
Is there a conformant way to test for this data in a way that makes sense? I’ve just given you numbers based on looking at watch.
Edit: It spends most of its time on Building for web.browser.legacy as far as I can tell. But why would this be different when doing the meteor reset? Does this mean that the 1.7.1 and node 8.12 will fix this problem, and this has nothing to do with killing the database?
It looks like 1.7.1 still needs to build the legacy bundle synchronously on a cold start, but defers it on hot reloads.
If you set the environment variable METEOR_PROFILE=100 it will log out how long the build takes.
The number 100 is the number of milisecods a task needs to take before it appears in the profile log, so this one will be filtered to show longer operations
If you want to see every step, set it to 0
And If you want to see even more output, set METEOR_DEBUG_BUILD=1
And if you want even more, Qualia have made a great profiling tool to generate a flamechart of CPU usage during meteor builds (and runtime): https://github.com/qualialabs/profile
5 minutes is unusual, so it might be worth looking at, but at the same time, if warm starts and dev rebuilds are fast, it might not be worth it
For comparison, on the project I’m currently working on (1.7.1-rc0)
| (#1) Total: 6,709 ms (ProjectContext resolveConstraints)
| (#2) Total: 4,455 ms (ProjectContext prepareProjectForBuild)
| (#3) Total: 64,269 ms (Build App)
=> Started MongoDB.
| (#1) Total: 1,583 ms (Server startup)
=> Started your app.
=> App running at: http://localhost:3000/
| (#1) Total: 1,379 ms (ProjectContext resolveConstraints)
| (#2) Total: 3,056 ms (ProjectContext prepareProjectForBuild)
| (#3) Total: 10,982 ms (Build App)
=> Started MongoDB.
| (#1) Total: 1,235 ms (Server startup)
=> Started your app.
=> App running at: http://localhost:3000/
| (#4) Total: 163 ms (ProjectContext prepareProjectForBuild)
| (#5) Total: 725 ms (Rebuild App)
=> Client modified – refreshing
=> Finished delayed build of web.browser.legacy in 1444ms
| (#6) Total: 206 ms (ProjectContext prepareProjectForBuild)
| (#7) Total: 1,050 ms (Rebuild App)
| (#1) Total: 1,268 ms (Server startup)
=> Meteor server restarted
=> Finished delayed build of web.browser.legacy in 2218ms
Notice how 1.7.1’s deferred legacy build saves 50-66% of reload times 
Very much appreciate information - this is some good stuff. Going to bookmark this. I’m totally waiting for 1.7.1 and node 8.12. First to admit don’t really understand this stuff, but totally need to learn.
Edit: much respect for messing around with rc’s. Even when i run into issues with Meteor, just not familiar enough to start making and committing changes.