-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Add caching around resolvePluginConfig() and only invalidate virtual modules when necessary #7908
Conversation
🦋 Changeset detectedLatest commit: cafa886 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR!
Also, thanks for the help, and for being so thorough! I really appreciate it. |
@markdalgleish I'm using |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Closes: #7868. This adds caching around
resolvePluginConfig()
to avoid recalculating routes hundreds of times on startup. There is one cache used forremix-react-refresh-babel
andremix-remove-server-exports
, and another used in the middleware to determine if the virtual modules need to be invalidated.I was unable to get a single cache working, as the cache would get updated in one of the other plugin transforms so there was no way to tell if it was stale for the route request by the time the middleware ran.
Testing Strategy:
Discussion with @pcattori, "we have pretty good tests for this sort of thing in integration/vite-dev-express-test so if those pass with your changes I'd be reasonably confident about it"
Also used this in developing our app the last couple of days, which included changing #and adding new routes and lots of HMR/HDR. I didn't run into a single stale cache issue with HMR/HDR, and performance was a ton better than 2.2.0 as released.
Benchmarking
On 2.2.0, my app startup took 24 seconds, HMR took 2+ seconds when there was a loader, and basic site navigation took around 2 seconds.
With the patch, app startup is just under 12 seconds and HMR with loaders and site nav are both around 400ms. (Note that some, but not all, of this improvement is due to the LiveReload logic fix added since 2.2.0).
Not profiled below, but my
vite build && vite build --ssr
times dropped from a combined 129 seconds to 24 seconds.2.2.0:
Patched: