It’s likely that many Meteor applications will still lack clearly defined entry points for client and server code. In other words, the meteor.mainModule keys in the package.json may not specify the initial files to load for both the client and server. If you create a new Meteor app using meteor create, you’ll see an example of how this configuration should look in the package.json.
The first step in improving performance is to define these entry points. By doing so, the Meteor bundler skip eagerly loading JavaScript modules, so identifying all modules used in the app, even those not directly referenced.
If you’re unable to modify the entry points or just want to compare performance without them first, you can use the METEOR_CLIENT_ENTRYPOINT and METEOR_SERVER_ENTRYPOINT environment variables. These variables should point to the initial client and server files or any other client-only and server-only files you wish to test. The profiling script then makes a change to these files, adding and removing a line, to simulate changes and trigger a rebuild for the time to be measured.
Let me know if you’ve tried profiling using these environment variables and whether defining entry points improves performance.
Thank you.
I created an empty main.js on the client and one on the server.
Result :
===============================
Meteor version - METEOR@3.2
===============================
Meteor options - --settings settings.json --exclude-archs web.browser.legacy,web.cordova
===============================
===============================
Metrics - Cold start
===============================
- Meteor(resolveConstraints): 3788 ms |
- Meteor(prepareProjectForBuild): 30741 ms
- Meteor(Build App): 70443 ms
- Meteor(Server startup): 4647 ms
* Total(Meteor): 109619 ms
===============================
Metrics - Cache start
===============================
- Meteor(resolveConstraints): 921 ms /
- Meteor(prepareProjectForBuild): 4411 ms
- Meteor(Build App): 36184 ms
- Meteor(Server startup): 4260 ms
* Total(Meteor): 45776 ms -
===============================
Metrics - Rebuild client
===============================
- Meteor(resolveConstraints): 908 ms |
- Meteor(prepareProjectForBuild): 4659 ms
- Meteor(Build App): 34327 ms
- Meteor(Server startup): 4138 ms
- Meteor(Rebuild App): 3781 ms
- Meteor(Rebuild App)#2: 3340 ms
* Total(Meteor): 51153 ms /
===============================
Metrics - Rebuild server
===============================
- Meteor(resolveConstraints): 908 ms \
- Meteor(prepareProjectForBuild): 4477 ms
- Meteor(Build App): 34393 ms
- Meteor(Server startup): 4081 ms
- Meteor(Rebuild App): 5459 ms
- Meteor(Rebuild App)#2: 5164 ms
* Total(Meteor): 54482 ms /
And il the log file :
| Top leaves:
| Babel.compile...........................................38,930 ms (3188)
| jsAnalyze.parse..........................................6,429 ms (9750)
| other plugin templating-compiler.........................5,473 ms (1)
| getPrelinkedFiles toStringWithSourceMap..................2,446 ms (354)
| linker File#getPrelinkedOutput...........................1,857 ms (6993)
| other linker File#computeAssignedVariables...............1,206 ms (7008)
| files.readFile...........................................1,114 ms (10730)
| files.writeFile..........................................1,066 ms (9014)
| other reifyCompileWithCache................................958 ms (688)
| other linker Module#getPrelinkedFiles......................755 ms (354)
| other PackageSourceBatch#_linkJS...........................644 ms (354)
| files.readdirWithTypes.....................................589 ms (13156)
| files.stat.................................................581 ms (19667)
| sha1.......................................................447 ms (43644)
| other ImportScanner#resolve................................396 ms (6784)
| other ImportScanner#findImportedModuleIdentifiers..........381 ms (5537)
| other Target#_emitResources................................335 ms (2)
| other ClientTarget#write...................................290 ms (1)
| files.rm_recursive.........................................290 ms (357)
| other ImportScanner#scanImports for webapp.................282 ms (2)
| other ImportScanner#scanImports for universe:i18n..........255 ms (2)
| findImportedModuleIdentifiersVisitor.......................249 ms (3729)
| other ImportScanner#realPath...............................225 ms (9022)
| files.rename...............................................212 ms (2746)
| other JsImage#write........................................212 ms (1)
| other ImportScanner#scanImports for rationalk:erp..........202 ms (2)
| files.watchFile............................................201 ms (19187)
| other linker.fullLink......................................193 ms (354)
| other PackageSource#_findSources for os....................192 ms (1)
| files.lstat................................................191 ms (16310)
| other PackageSourceBatch.computeJsOutputFilesMap...........168 ms (2)
| other bundler writeSiteArchive.............................156 ms (1)
| sha512.....................................................139 ms (5176)
| other Builder#copyNodeModulesDirectory.....................126 ms (39)
| other safeWatcher.watch....................................121 ms (42737)
| other compileUnibuild (the app)............................109 ms (3)
| other bundler writeFile....................................100 ms (3274)
|
| (#3) Total: 70,443 ms (Build App)
Thanks for sharing your profiles. I’m curious about the main entry points for meteor.mainModule in your app. For example, a configuration in package.json might look like this:
These entry points act as the files that load all the other modules for the client and server. Using these entry points ensures only the “tree” files that are actually imported by these files get loaded, rather than eagerly loading every JS file in your project folder. Setting this up could be a helpful improvement, and I’d like to know if it makes any difference in the profiles. Could you try this and get again the profiles? Or is there a particular limitation preventing you from configuring it this way?
I tried running meteor profile XXX instead of meteor run XXX for our app, but it crashed after a while. Is there any additional diagnostic output I can enable?
The error in the log file is:
/…/node_modules/.cache/meteor/performance/scripts/monitor-bundler.sh: line 189: 59655 Killed: 9 METEOR_PROFILE=“${METEOR_PROFILE:-1}}” METEOR_PACKAGE_DIRS=“${METEOR_PACKAGE_DIRS}” ${meteorCmd} run ${meteorOptions}
The output on the command line (slightly redacted):
===============================
Profile script
===============================
- App path: /PATH
- App port: 3000
- Logs file: /PATH/logs/1743447797259-refapp-bundle.log
===============================
===============================
Full log details at /PATH/logs/1743447797259-refapp-bundle.log
===============================
* Profiling "Cold start"... |
=============================== -
An error occurred when profiling. For more details, check at /PATH/logs/1743447797259-refapp-bundle.log
===============================
zsh: killed yarn debug:nointegrations:profile
Entrypoints should be files that serve as the starting point for importing the rest of the project. Due to the nature of the project (possibly related to Blaze or FlowRouter), it might not support entrypoints. Since I’m not familiar with that stack, I can’t confirm. Perhaps @jkuester or @harry97 could provide more insight. Have you seen any Blaze projects defining “meteor.mainModule” entrypoints?
@permb and @storyteller: Could you try running the profile with a higher idle timeout, such as with the env METEOR_IDLE_TIMEOUT=360?
The default is 1.5 minutes (METEOR_IDLE_TIMEOUT=90), but it seems possible that some apps, especially during cold starts without a cache, might take longer. Increasing the timeout will help confirm if that’s the case. I’ve suggested a higher value above to rule out other issues, though hopefully it won’t take more than six minutes for you. In any case, SWC will help significantly.
The summary will be enough for now. Including the initial (#3) Total: xx ms (Build App) section with the Top leaves would help confirm the most common profile processes. It’s likely they’ll match what we and others typically see, but it’s worth checking in case something different shows up.
In any case, we’ll see the new results once the first 3.3 beta is available with SWC and other optimizations. Thank you for your help!
EDIT: We’re currently on 3.1 but I’ll definitely work on updating our application to the latest version so we can help in the bundle improvements efforts.
Whether using Blaze or React, entry points define where your application starts running on both the client and server sides. These are specified in your package.json file under the "meteor" section. You can take a look at our tutorial app to understand it.
This tells Meteor which files to execute first when the application starts: package.json
@victor, @dokithonon: Could you update your messages above to share the NPM and Atmosphere packages lists from the profile log?
Feel free to send them privately if you prefer. I got this idea from @storyteller’s performance profile, which includes a project heavily reliant on Babel with multiple plugins. That’s a great reference to see how those plugins perform as we implement SWC support. Since SWC replaces Babel, any plugins without equivalents won’t benefit from the switch. A list of dependencies would help us test them in isolation and observe how they perform.
In my case with the exception of react-compiler and to lesser degree the styled-components babel plugins, the rest I can do without. For Storybook there is either Webpack or Vite, so moving to either of them (preferably Vite) would make my setup easier.
Interestingly, when running meteor profile instead of meteor run, the plugin cache for refapp:meteor-typescript does not seem enabled. Is that by design? If so, is there a way to re-enable it to get a profile for when caches ARE available?
Just a suggestion: if you have an app without mainModule set, Meteor generates a single file with all of the eager imports anyway – it’ll be visible in your browser’s devtools. What we did a couple of years back was copy this file verbatim (of course we replaced the reified requires into imports) into client.ts and made it the mainModule. Then you can do the same on the server – it should be easy to find with --inspect-brk.
Maybe there could be a meteor generate-main-module command to do that automatically?
with the entrypoints in package.json
In any case, SWC will help significantly. 