wip: collect css information in worker #83
Conversation
Even though this plugin is smarter than using postcss with globs, it's still a pretty significant contributor to Vite slowness (in our large app, it adds 5-10 seconds to the first page load, depending on how big the first page load is) if there are no transformations being done in the plugin, it could make sense to do the parsing in a seperate worker so that it doesn't slow down the main Vite transformation pipeline. This just proves out the idea, and isn't ready to be merged or anything. See "TODO" comments for a number of things that would be needed if we decide this is worth doing. You can see the benefit by running the make-files.sh script, then doing `pnpm dev` in the playground with/without the "worker" option in the vite plugin.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
|
||
| let latestCss: string | undefined | ||
| // Necessary because when using virtual:pandacss in cases with many files, | ||
| // the css may be empty the first time the page is loaded, and HMR doesn't work if the page hasn't loaded yet. |
There was a problem hiding this comment.
I need to do more testing here. This might only be necessary the first time css is loaded, or it might not be necessary at all if we keep track of if the worker has anything in progress and await it.
|
super interesting! I'm not sure to follow; how does it behave with a worker ? assuming it takes 5-10s (blocking without a worker); now the vite dev server would start instantly again but then the app would not have any style for 5-10s ? have you tried generating a .cpuprofile (you can inspect it in https://www.speedscope.app/ or within VSCode) to see where most of the time was spent ? if its anything else than the AST parsing we could maybe improve it |
| let lastCss: string | undefined | ||
|
|
||
| let latestCss: string | undefined | ||
| // Necessary because when using virtual:pandacss in cases with many files, |
There was a problem hiding this comment.
does that imply that there's no issue when using an actual file ? with options.outfile
There was a problem hiding this comment.
That's right, I didn't see the issue when testing with outfile. I wish I understood better why it's different
|
Compared to a current build that takes 10 seconds today (5s in pandabox, and 5s on other transforms), this change should make it take 5 second. Because the worker is in a different thread, the CSS seems to finish about the same time as other transforms. It's just faster because it's parallel. |
|
Based on a profile, most of the work is ts-morph stuff from |
|
Here's the speedscope of the playground app with the many files generated The transform time is similar in our real app, but |
Even though this plugin is smarter than using postcss with globs, it's still a pretty significant contributor to Vite slowness (in our large app, it adds 5-10 seconds to the first page load, depending on how big the first page load is)
if there are no transformations being done in the plugin, it could make sense to do the parsing in a seperate worker so that it doesn't slow down the main Vite transformation pipeline.
This just proves out the idea, and isn't ready to be merged or anything. See "TODO" comments for a number of things that would be needed if we decide this is worth doing.
You can see the benefit by running the make-files.sh script, then doing
pnpm devin the playground with/without the "worker" option in the vite plugin.