@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?
When I run the profiler, one of my files is getting altered to have a console.log('new line') added to the same line as an import which breaks the compile step.
console.log(‘new line’) appears nowhere in my own code, my version control has no uncommitted changes when I start the process and has that change at the end of the process. This only occurs when profiling and not when running normally.
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)
In any case, SWC will help significantly. 