-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
perf: unresolvedUrlToModule promise cache #12725
Conversation
Run & review this pull request in StackBlitz Codeflow. |
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.
I was able to see a promise cache hit when combined with vite-plugin-warmup
sometimes, especially when combined with a slow resolving plugin:
{
name: 'slow',
enforce: 'pre',
async resolveId(id) {
await new Promise((resolve) => setTimeout(resolve, 10))
},
},
But it's not always reproducible, and kinda an edgecase depending on the configuration. If the iife and promise doesn't incur much overhead, I guess we could continue with it still.
We discussed this a bit more with @antfu, he is a bit concerned about merging this without more perf data. My take is that we should still merge this given that it makes the API more robust, and not only more performant. Still, I would like to wait for @sapphi-red's here. Maybe in some of his test cases would make the decision more clear. |
The time didn't change on my machine. (I guess it's within the margin of error.) before
after
|
I wonder if there would be a difference if we change this part to use vite/packages/vite/src/node/plugins/importAnalysis.ts Lines 412 to 673 in 8e30025
|
That's a good idea @sapphi-red. I was thinking about the same while reviewing #12619. But I didn't connect it to this PR. It may have a bigger effect after #12723 though. Worth exploring, I'll check it out if nobody beats me to it. |
I think we should merge this PR, even if the perf improvement is minimal it makes the API more robust. |
Description
wip
We thought this could have an effect, but in the examples we tried there are no concurrent callings of resolveUrl and ensureEntryFromUrl. @bluwy @sapphi-red maybe you could check in some of your apps.
I still think it is better to keep the promise given that these public functions could be called externally.
What is the purpose of this pull request?