No that I’m aware of.
Would you like to create one?
Ok, did that right here HMR Slowness with Meteor 3.0.3 + React + MUI6 · Issue #13430 · meteor/meteor · GitHub
4 Likes
I want to update that after some research, I believe I found the fix. I still need to verify it with the example app provided. I will do this next.
More details are available on the PR. Hopefully, we can include it in the next version.
4 Likes
Hi @nachocodoner, the beta of 3.1 has it fixed. I tested and in development changes are instantly reflected in the browser.
(also copying @leonardoventurini )
2 Likes
I’d also like to try this, how can I use 3.1?
Strange, since these changes appeared after the 3.1 beta release. I can’t think of another change in the 3.1 beta that could have affected the build.
Alternatively, there might have been an issue with the record package usage, as @minhna reported, which was fixed automatically on the server status when you tested it. In my debugging, I didn’t notice any major changes in the package recording, but I did find other slowdowns in the build itself, which seem to be a negative impact and provided a fix already. I’ll review the recordPackageUsage to see if it’s affecting the rebuild flow under poor network conditions.
But definitely any of these changes would be available on the next beta or release.
Ok, I will update my largest project now and get back soon.
Ok, with this: Super slow HMR in meteor 3.0 - #8 by minhna, it takes less than a second (which I’d call instantly).
After removing that record from hosts, it takes between 1 and 3 seconds. I mean sometimes 1 sometimes 3
1 Like
Recording packages stats definitely caused slowdowns, included this fix as well as part of the set of changes for next release.
2 Likes
We’ve released a new RC version of Meteor 3.1, including the fixes noted here and in the PR.
meteor update --release 3.1-rc.0
If you can test it, please do and share your feedback.
1 Like
Tested and as we say in engineering … 60% of the time works every time 
Looks good, I would consider it fixed.
2 Likes
Official Meteor 3.1 has been released, including the fix mentioned in this thread.
Update your app and share any feedback.
meteor update --release 3.1
3 Likes
After updating to 3.1 I am still getting about 10 second rebuild time. My project is pretty complicated, but I would love to be able to dive in and figure out what is actually causing the problem.
Is there any suggestions on how to debug further
|
| Top leaves:
| Babel.compile............................................5,147 ms (1085)
| jsAnalyze.parse..........................................2,163 ms (1044)
| other ImportScanner#resolve................................779 ms (15803)
| other ImportScanner#realPath...............................506 ms (6455)
| getPrelinkedFiles toStringWithSourceMap....................506 ms (1)
| ImportScanner#readFile.....................................264 ms (2604)
| sha512.....................................................249 ms (5260)
| files.readdirWithTypes.....................................243 ms (1356)
| sha1.......................................................189 ms (15132)
| findImportedModuleIdentifiersVisitor.......................163 ms (1044)
| files.writeFile............................................119 ms (6)
|
| (#5) Total: 11,375 ms (Rebuild App)
|
This is after changing just one file, which should be fast.
Note, this is about half the time it used to take, so there are definitely improvements, but in general I’m at a loss on how to dive deeper into it.
With version 3.1, it took only 3 seconds. Awesome.
2 Likes
No improvements at all in your app?
I’m seeing positive numbers across several apps on my end, with others also reporting gains. I’m curious about how your setup and verification process differ.
Does your rebuild involve client-only code, or does it include both server and client? The improvements here mainly benefit HMR response times, which is a client-only feature. You can check the logs to see if “Server restart” appears. If modifying client code also restarts the server, it could indicate that your setup is eagerly compiling server-side modules.
If the server doesn’t restart (indicating client-only changes) and you’re still seeing long compile times, you might be eagerly importing heavy client dependencies. Could you share a list of dependencies you use? Are you using MUI, an icon library, or other large npm packages? Do you import only the modules you need from these packages?
I also recommend using bundle-visualizer for deeper insights into your client app’s dependencies and bundle size: Bundle Visualizer | Docs.
It would be helpful to understand more about your app.
Oh there was definite improvement after this update, but its still pretty slow. I do have MUI, and it is a pretty hefty project overall.
This is a client only update.
Maybe I’m just imagining meteor is doing more magic than it is, but my React-Native project that runs 90% of the same code updates in less than half a second, so 10 seconds still feels like a lot.
Does Meteor have to recompile the full initial bundle every time one file is changed? Right now my initial bundle does appear to have mui, firebase and react-native-web which are about 600kb total. But those just don’t change, so I would assume an HMR could just inject the new code without being slowed down by those.
All together bundle visualize says my bundle is 3.3Mb (which i will work to cut down), what you are saying is that initial bundle is a main thing to work on to improve reload times? What about number of unique bundles does that affect it?
Is there some resource that just points to all the different things that might be increasing this time?
Could you please post an example of how you import MUI packages?
Specially how you import the icons if you use MUI.
Icons is usually an issue in general on any framework. I use MUI on my Meteor app and I do import all of them using specific paths, instead of direct paths. There shouldn’t be any direct path import reference of icons otherwise the entire catalog is imported in one go, which slowdowns drastrically your rebuild times.
// direct path
import { ReceiptLongOutlinedIcon } from '@mui/icons-material';
// specific path
import ReceiptLongOutlinedIcon from '@mui/icons-material/ReceiptLongOutlined';
In general, it is good to act on reduce the bundle as much as possible. Specific imports is a strategy in Meteor to improve it.
I’m glad to know that you felt improvements on rebuilds, even though in your app case, it seems to be more an issue on the size and how import modules. Hopefully you can find specific imports that can give you more speed.
1 Like
React Icons is another example. Their website provides instructions on using it with Meteor.js.
npm install @react-icons/all-files --save
import { FaBeer } from "@react-icons/all-files/fa/FaBeer";