Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Dev open slow:Can you quickly compute the hash while parsing the request to return 304 #11859

Closed
4 tasks done
meedfine opened this issue Jan 31, 2023 · 1 comment
Closed
4 tasks done

Comments

@meedfine
Copy link

Description

link to #1309
Evan says: we can dump the in memory transform cache to disk on server close, and "hydrate" the module graph on next server start
i just think: if we can quickly compute every request hash, and use disk cache to save the relation of etag and hash
{
'xx etag': 'xx hash'
}
while restart the server, if a req's hash and etag matched,maybe we can quickly return 304 ,to avoid some slow part of the module processing
similar to #10671

Suggested solution

...

Alternative

No response

Additional context

No response

Validations

@ArnaudBarre
Copy link
Member

This solution has all the same problems of cache invalidation that the linked PRs. For now we've put on hold the idea of caching at this level, and we're trying the see how to improve perf without caching or with more granular caching

@vitejs vitejs locked and limited conversation to collaborators Feb 8, 2023
@bluwy bluwy converted this issue into discussion #11982 Feb 8, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants