New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading caniuse-lite takes ~0.5sec, could the cache be persisted on disk? #1492
Comments
How do you plan to add better cache? |
i want the cache to be persisted between compilation runs. so restarting compilation process would be slightly faster. it can also thus be shared between different processes (like production webpack runs and storybook builds etc.) |
Running
|
Yes, I understand the problem (honestly, it mostly came from What solution do you suggest? |
the times above are plain node, without ts-node. The |
First small thing - changing
to
removes the big cost to load whole caniuse-lite for loading just browser stats - this same import is used by browserslist to calculate usage. So that leaves only the feature require. |
You need to think about cache invalidation on It could be much more complex, than you think.
Yes, we can change it. Send PR. |
And changing
to
results in total time of 100ms. So without any caching, these two imports reduce startup time from ~300ms to ~100ms. |
PR incoming. |
The fix was released in 10.4.14. |
On my machine the require("caniuse-lite") can take around 450ms. This is relatively noticeable slowdown every time some compilation is started. This might be more than usual because i have ts-node etc. but overall my setup is rather straight forward webpack+postcss. Building the prefixes list takes another ~50ms.
I am planning to patch autoprefixer to persist the current in-memory cache to disk to avoid this. Would you be willing to consider this as a PR as well? (just so i know if i can cut corners or if i should make things properly, with configuration options etc.)
The text was updated successfully, but these errors were encountered: