Improve dev mode performance

[Janpot]

As per last retro, removing this (import { Error as ErrorIcon } from '@mui/icons-material';) import improves performance a lot. For now we can just pass a component down. Hopefully we can eventually move forward with mui/material-ui#30510

Alternatively we can explore compiling these packages to commonjs

@apedroferreira @bytasv please try out in your local and let me know if it improves things

[render]

Your Render PR Server URL is https://toolpad-pr-1232.onrender.com.

Follow its progress at https://dashboard.render.com/web/srv-cde0344gqg42mra7c6mg.

[bytasv]

Hmm, I can't really tell the difference between how these changes work and what was before 🤔

Could it be that we are looking at different things? I'm checking by switching between pages, but it "feels" like the time it takes to load is very similar. Nevertheless approving this ✅

Screen.Recording.2022-10-31.at.12.14.40.mov

[Janpot]

I didn't measure it exactly, but I see a clear difference:
before:

Screen.Recording.2022-10-31.at.11.21.01.mov

after:

Screen.Recording.2022-10-31.at.11.21.39.mov

Also Toolpad is much more responsive while switching the pages, I can actually click the hierarchy menus now.

[bytasv]

I can see the difference in your recording, but I'm unable to reproduce same on my machine 🤔 are you running yarn dev or something different? Curious if Pedro will be able to feel the difference and why I'm not seeing the same 🤔

[Janpot]

are you running yarn dev or something different?

In usually run yarn && yarn dev after switching branches. How are you checking out the code of this PR?

[bytasv]

How are you checking out the code of this PR?

I have checked out branch locally, just tried to run yarn to install/refresh deps if anything is missing, then ran yarn dev. Wondering could it be related to how docker is set up? I.e. maybe you have more resources allocated 🤔

@apedroferreira could you also check? While it seems that I might be missing something on my end, it would be good to verify

[Janpot]

Wondering could it be related to how docker is set up?

I doubt it, only the database is running in docker in development mode.

[apedroferreira]

Doesn't really make a difference for me... My console shows the time each route takes to compile and the wait times are pretty huge:

Here some of them take about 5 seconds and one of them more than 30 seconds. So it can take a long time for me to open an app for the first time in dev - once it shows it's faster with the hot reload.

Another run: 5.7s + 14s + 3.4s, not sure if these times are unusual:

[Janpot]

It's important to understand that Next.js optimizes for startup time in dev mode. That means it will compile sources on-demand. As soon as it is compiled once, the HMR should make incremental compilation faster. The consequence is that the first time opening a page will be a little slower. It's either this or longer startup time. Here's to hoping that the upcoming turbopack update will make this a lot faster still. I don't think there's much we can do here, maybe we can profile some internals? All in all, I don't think it makes much sense to look at initial compile time. If there are reasons why you often have to restart the application, I'd love to hear about it.

[bytasv]

I personally don't care much about initial load time as I understand it always takes longer. The problem is that page load time for me doesn't change even when I'm not changing any code, i.e. I just click back and forth between pages it takes as much time as in your video of "before". That's why I'm puzzled why I'm not seeing same improvement as you do 🤔

[apedroferreira]

If we can't find any more quick wins I'm fine with things staying as they are and hoping upcoming Next.js updates improve things, it's not that bad of an issue to spend more time on it in my opinion.