@zodern I believe this would be a nice case for you to investigate.
I did a quick profile here and it seems they (mui) are somehow deferring the evaluating of modules, I didn’t check their code but in the profile I see the runSetters calls running later so I think they are using something to avoid importing all the modules in the first load.
It seems something started by insertStyles function.
I think this is the same issue as Unexpected module.runSetters wrapping · Issue #277 · benjamn/reify · GitHub. In the code there are parameters that have the same name as exports, and where the parameters are reassigned reify is unnecessarily calling runSetters. ~90% of the time is spent by runSetters, and quickly looking through the code I don’t see anywhere that it needs to be run.
would this be Meteor’s code or MUI causing the issue? I could link the issue you posted on my MUI issue post.
The issue is in reify, which Meteor uses as part of its module system.
Thank you for your help!!
We are going to start trying to fix this issue in a few weeks.
Thank you, appreciate it!!
Same issue here. The fix would be a great performance improvements for those using MUI5.
Really looking forward to it.
At this point, you could say that material-ui v5 is not compatible with Meteor 
Au contraire mon frere. I’m using Material v5 and it’s great. There’s a very small delay on the opening of the nav menu the first time which I never noticed before, and it will be nice to have it fixed.
It depends on the complexity of the app, but it’s more than just a small delay on one component. Every new component tree will add a delay, so every menu, every new route, every conditional element etc. Of course, it’s only for the first time, but users tend to refresh or close their browser from time to time
And it’s not just a delay. Browser freezes for 600ms in our app and if you have any animations, spinners for example, it’s very visible.
I have the same issue. Hope @filipenevola is working on a fix. MUI v5 is great and I’d hate to have to downgrade.
You know, I think you’re right. Is there a practice for measuring the browser freeze time, or do you tell just by observation? I think I’m seeing the same thing in my app.
The best way to measure is to use performance profiler in chrome.
Hi, we are aware and this is at the top of our queue so we are going to invest time on this soon.
You can keep yourself up-to-date with the progress here.
I’m seeing load times in the performance profiler for many different things. Nothing seems to be labeled “mui” or “material”. Is there a way to find out, how much of the load time is related to material-ui?
I have already tested with beta 5 and it seems to be that is now faster the first time when I open the menu dialog.
http://localhost:3000/home/users
This is a project example where I did my tests: Scaffold Meteor React
2.5.2 Beta 5 version is on branch meteor-latest and 2.5.1 is on branch dev. So, you can compare times.
Tested on Macbook Pro 16’ (2019) Intel
Meteor 2.5.2 is released and recommended. This lag is fixed in this version.
