Yes, that’s the part of the process that simulates a rebuild by temporarily adding and then removing a line. I wouldn’t expect it to break compilation as in your case; it’s meant to be a simple addition. Perhaps this is an edge case. What OS are you using? Could you share the file contents with me privately if you’d prefer? Also, try adding a blank line in that file and running it again.
Alternatively, you could create a new “mock” file, import it from your entry point, and set its path in the METEOR_CLIENT_ENTRYPOINT and METEOR_SERVER_ENTRYPOINT env variables. You could also point those vars to an existing file in your code, ensuring it’s client-only for METEOR_CLIENT_ENTRYPOINT and server-only for METEOR_SERVER_ENTRYPOINT. After these changes run the meteor profile again.
The file literally just has import '..import/startup/client' in it. Running now with some new lines in it as I think your right that should fix it. It just broke it because it was becoming import '..import/startup/client'console.log('new line')
It’s already got further than it did on previous attempts so that appears to have done the trick.
Thank you for the report. I’ll address this by adding a new line each time before if needed.
Another option could be running touch <entrypoint> to prompt the bundler without modifying the file, not sure if it will work cross-OS, but I will try it. However, the bundler might not detect any change and still use the cache, which is why adding a new line with new content could be necessary.
I was very keen to try this as my build is crazy slow. Very interesting to see that it is sqlite query causing the majority of the issues rather than babel like most people. Is this likely because my queries are poorly optimised? That wouldn’t be surprising, this was the first project I built professionally and certainly would do lots of things differently database wise if I were to start over.
Top leaves:
| sqlite query…63,937 ms (1)
| Babel.compile…32,077 ms (979)
| files.readFile…3,880 ms (18927)
| jsAnalyze.parse…3,825 ms (5548)
| other reifyCompileWithCache…2,950 ms (4465)
| getPrelinkedFiles toStringWithSourceMap…2,225 ms (222)
| other ImportScanner#resolve…1,778 ms (21937)
| files.stat…1,750 ms (32410)
| files.writeFile…1,286 ms (4664)
Meteor uses a SQLite database to track the remote catalog of Atmosphere packages for offline usage. After running a profile with the official release (not a Git checkout as I normally use to work on), I saw that SQLite queries take a huge amount of time. Apparently having your projects running from a Meteor Git checkout this SQLite database is not queried the same way as part of dev mode, and it could make you save even more, you can check out with meteor profile if you try out the approach.
There’s clearly room for improvement for published releases on managing this local database, and your profile, along with others I’ve taken locally, shows that. We’ll work on this for the next 3.3 beta.
For now, everyone can test the SWC delivery in the first 3.3-beta.0.
Update: Check this profile comparing running from a published release (3.3-beta.0) vs a meteor git check out (release-3.3 branch) with the same changes.
Rebuilds are similar. Builds are slower in published releases due to some SQLite DB queries running distinctly. In Meteor checkout, only prepareProjectForBuild is slower the first time; after that, performance improves. We should look into this.
On ubuntu (also osX 15.4.1) I got this An error occurred when profiling and in the last line of the logs it says.
.../node_modules/.cache/meteor/performance/scripts/monitor-bundler.sh: line 201: 71571 Killed METEOR_PROFILE="${METEOR_PROFILE:-1}}" METEOR_PACKAGE_DIRS="${METEOR_PACKAGE_DIRS}" ${meteorCmd} run ${meteorOptions}
Another issue is that the process says is got killed but in the console it keeps spinning
Since it seems to finish the Cold and Cache phases and gets stuck on the rebuild client phase, the issue might be missing break lines at the end of your app’s entrypoint files.
Check your Meteor config in package.json to see which files those are, and make sure they end with a break line. I haven’t fixed this yet. Hopefully, it’s just that, along with setting a higher timeout.
Will it be possible to add the time to client refresh and to hmr? Probably not important if we are moving to vite.
Yes, the time to refresh client and server is within the “Rebuild client” and “Rebuild server” phases. Specifically, the stages including #1 and #2, which correspond to the two file change that triggered rebuilds.
To clarify, I added new entries to the meteor profile output: Total(Rebuild #1) and Total(Rebuild #2). These sum up the prepareProjectForBuild, Rebuild App, and Server Startup (only in server rebuild) stages for each run. This should give a clearer view of what’s relevant in that phase. To see the full rebuild metrics, use meteor reset and run profiling again.
I enjoy seeing the profiles you share and the actual improvements in your projects. Meteor profiling has also been a quick way for each developer to check their own machines and, like you did, compare setups to see which one gives the best dev experience. Our time is valuable, and having a proper machine is a solid investment for daily work.
We’re planning a new set of changes that should lower those numbers even more.
To me, Meteor 3.3 is all about focusing on what Meteor really is, so we can support the bundler that builds our apps up to the point where we hit its limits.
Meteor 3.4 will push those numbers down further, as more of your app’s processes, like watching, transpiling, compiling, and minifying, will be delegated to a modern bundler. That lets Meteor concentrate on what matters: Atmosphere packages, the dev server, Mongo dev experience, and other specifics of the tool we love.
I’d love to test the refapp:meteor-typescript compiler too but it’s a bit complicated since, for unknown legacy reasons, a published compiler does NOT use dependencies from the meteor version you compile for but instead dependencies (e.g. BabelCompiler) that are published in the compiler package itself.
So to test, I would need to republish a new version of the compiler with meteor publish --release 3.3-beta0…
Will do that but not right now.
And I would love to understand why on earth isobuild published compilers don’t use dependencies from the meteor version it’s compiling for. I would guess this decision is lost in the annals of time…
I have new results from running profile with the new 3.3-beta.1. The project has changed since the last profile so I can only compare modern: true with modern: false.
osX profiling
metric
modern beta.1
old
diff %
Cold start
20,830
32,782
-36.5%
Cache start
12,183
14,163
-14.0%
Rebuild client
13,810
16,391
-15.7%
Rebuild server
17,581
20,178
-12.9%
Im getting an error on the console. I dont know if this affects the times on the profile.
Parcel watcher error on /Users/paulomogollon/Proyectos/okarai/builder: [Error: Events were dropped by the FSEvents client. File system must be re-scanned.]
Could you use the Total(Rebuild #1) time to label “Rebuild client” and “Rebuild server” in your tables? That reflects the full refresh time for HMR being the most interesting output. If you don’t see those totals, try clearing your node_modules, reinstalling, and profiling again.
Regarding the error: we’ve switched to a newer watcher in beta.1 that uses native cross-platform watchers. Can you share your OS and version? I’ll look for common fixes. In the meantime, does dev mode still reload on changes? Does the error show on every change or only when you start the app?
Sure, this are the results with both client and server rebuild times
osX profiling
metric
modern beta.1
old
diff % (old-beta.1)
Cold start
21,546
33,387
-35.5%
Cache start
14,484
14,205
2.0%
Rebuild client
13,506
16,447
-17.9%
Rebuild server
17,285
20,336
-15.0%
Rebuild app #1 (client)
1,131
1,554
-27.2%
Rebuild app #1 (server)
1,538
1,948
-21.0%
The error only happens on meteor start, on reloads it doesnt happen. Everything works as expected but I get that error on the console. Im using OSX 15.4.1
For some reason every time I run the profiler, it fails, and the git diff shows it removed the last line of client/main.js
I added a new line and it works fine. Might want to make sure whatever code modifies client/main.js for rebuild testing takes into account files that may not end with a new line.
After running successfully, the working directory is no longer clean:
wreiske@Wills-MacBook-Pro-M2 bluehive-ai % git diff client server
diff --git a/client/main.js b/client/main.js
index 135d466..c127c34 100644
--- a/client/main.js
+++ b/client/main.js
@@ -154,4 +154,4 @@ Template.criticalErrorModal.helpers({
criticalError: function () {
return Session.get('criticalError');
},
-});
\ No newline at end of file
+});
diff --git a/server/main.js b/server/main.js
index fd9d474..819ac3f 100644
--- a/server/main.js
+++ b/server/main.js
@@ -2414,4 +2414,3 @@ export const supportedWhisperLanguages = [
{ name: 'Urdu', code: 'ur' },
{ name: 'Vietnamese', code: 'vi' },
{ name: 'Welsh', code: 'cy' }
-];
\ No newline at end of file
===============================
===============================
Meteor config
===============================
{
"mainModule": {
"client": "client/main.js",
"server": "server/main.js"
},
"testModule": "tests/main.js"
}
===============================
===============================
Meteor version - METEOR@3.2.2
===============================
Meteor options - --settings=settings.json
===============================
===============================
Metrics - Cold start
===============================
- Meteor(resolveConstraints): 1580 ms
- Meteor(prepareProjectForBuild): 606 ms
- Meteor(Build App): 23164 ms
- Meteor(Server startup): 861 ms
* Total(Meteor): 26211 ms
===============================
Metrics - Cache start
===============================
- Meteor(resolveConstraints): 290 ms
- Meteor(prepareProjectForBuild): 442 ms
- Meteor(Build App): 7744 ms
- Meteor(Server startup): 557 ms
* Total(Meteor): 9033 ms
===============================
Metrics - Rebuild client
===============================
- Meteor(resolveConstraints): 293 ms
- Meteor(prepareProjectForBuild): 441 ms
- Meteor(Build App): 7852 ms
- Meteor(Server startup): 543 ms
- Meteor(prepareProjectForBuild #1): 25 ms
- Meteor(Rebuild App #1): 941 ms
- Meteor(prepareProjectForBuild #2): 23 ms
- Meteor(Rebuild App #2): 683 ms
* Total(Meteor): 10801 ms
* Total(Rebuild #1): 966 ms
* Total(Rebuild #2): 706 ms \
===============================
Metrics - Rebuild server
===============================
- Meteor(resolveConstraints): 292 ms
- Meteor(prepareProjectForBuild): 444 ms
- Meteor(Build App): 7893 ms
- Meteor(Server startup): 545 ms
- Meteor(prepareProjectForBuild #1): 27 ms
- Meteor(Rebuild App #1): 1221 ms
- Meteor(Server startup #1): 525 ms
- Meteor(prepareProjectForBuild #2): 25 ms
- Meteor(Rebuild App #2): 935 ms
- Meteor(Server startup #2): 530 ms
* Total(Meteor): 12437 ms
* Total(Rebuild #1): 1773 ms
* Total(Rebuild #2): 1490 ms
===============================
===============================
Meteor version - METEOR@3.3-beta.1
===============================
Meteor options - --settings=settings.json
===============================
===============================
Metrics - Cold start
===============================
- Meteor(resolveConstraints): 1560 ms
- Meteor(prepareProjectForBuild): 561 ms
- Meteor(Build App): 6705 ms
- Meteor(Server startup): 836 ms
* Total(Meteor): 9662 ms
===============================
Metrics - Cache start
===============================
- Meteor(resolveConstraints): 319 ms -
- Meteor(prepareProjectForBuild): 584 ms
- Meteor(Build App): 3634 ms
- Meteor(Server startup): 567 ms
* Total(Meteor): 5104 ms
===============================
Metrics - Rebuild client
===============================
- Meteor(resolveConstraints): 300 ms
- Meteor(prepareProjectForBuild): 577 ms
- Meteor(Build App): 3314 ms
- Meteor(Server startup): 568 ms
- Meteor(prepareProjectForBuild #1): 107 ms
- Meteor(Rebuild App #1): 306 ms
- Meteor(prepareProjectForBuild #2): 107 ms
- Meteor(Rebuild App #2): 248 ms
* Total(Meteor): 5527 ms
* Total(Rebuild #1): 413 ms
* Total(Rebuild #2): 355 ms
===============================
Metrics - Rebuild server
===============================
- Meteor(resolveConstraints): 290 ms \
- Meteor(prepareProjectForBuild): 562 ms
- Meteor(Build App): 3304 ms
- Meteor(Server startup): 564 ms
- Meteor(prepareProjectForBuild #1): 104 ms
- Meteor(Rebuild App #1): 506 ms
- Meteor(Server startup #1): 528 ms
- Meteor(prepareProjectForBuild #2): 109 ms
- Meteor(Rebuild App #2): 412 ms
- Meteor(Server startup #2): 836 ms
* Total(Meteor): 7215 ms
* Total(Rebuild #1): 1138 ms
* Total(Rebuild #2): 1357 ms
===============================
Here’s a friendly, high-level look at what changed between Meteor 3.2.2 and 3.3-beta.1:
Total Times Comparison
Metric
3.2.2 (ms)
3.3-beta.1 (ms)
Δ (ms)
Δ (%)
Cold start
26 211
9 662
–16 549
–63% faster
Cache start
9 033
5 104
–3 929
–43% faster
Rebuild client
10 801
5 527
–5 274
–49% faster
Rebuild server
12 437
7 215
–5 222
–42% faster
Breakdown of Key Phases
Build App
Cold start: from ~23 164 ms down to ~6 705 ms
Cache start: from ~7 744 ms down to ~3 634 ms
Rebuild (client): from ~7 852 ms to ~3 314 ms
Rebuild (server): from ~7 893 ms to ~3 304 ms
This is where most of the win comes from—Meteor’s core build pipeline got a big speed boost.
resolveConstraints & prepareProjectForBuild
These are roughly the same (300–600 ms range) across both versions, with small fluctuations.
Server startup
Steady at ~540–860 ms in all scenarios.
Hot rebuilds
Client: first delta from ~966 ms → ~413 ms (≈57% faster), second from ~706 ms → ~355 ms (≈50% faster).
Server: first delta from ~1 773 ms → ~1 138 ms (≈36% faster), second from ~1 490 ms → ~1 357 ms (≈9% faster).
Bottom Line
Upgrading to 3.3-beta.1 slashes your build times across the board—especially the heavy “Build App” phase. Cold starts go from ~26 s to under 10 s and rebuilds are roughly twice as fast. It’s still a beta, but these gains are a solid preview of what’s coming!
I reproduced this on my Mac M1. It only shows with meteor profile on macOS. Did you see it during a normal meteor run in development mode?
I know this issue. I’ve struggled to force rebuilds so logs append on a new line across OSs without leaving git changes or undoing other staged work. I’ll keep working on a clean fix.
That matches my tests, most gains are in the build/rebuild phases and with those percentages. We also tried to optimize prepareProjectForBuild and server startup. Saving a few ms is really hard in Meteor’s Node environment; offloading processing to Rust-based tools may push Node’s limits, as we did achieve with SWC.
Thanks for sharing this detailed report. They’ll encourage others to adopt the modern setup.
However, the bundler might not detect any change and still use the cache, which is why adding a new line with new content could be necessary.
Meteor profiling has also been a quick way for each developer to check their own machines and, like you did, compare setups to see which one gives the best dev experience. Our time is valuable, and having a proper machine is a solid investment for daily work.
Total Times Comparison
Breakdown of Key Phases
Bottom Line