-
Notifications
You must be signed in to change notification settings - Fork 335
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
Experimental code cache for built-in js/ts modules #204
Conversation
fb042d0
to
4db166c
Compare
Won't this use unbounded memory as more and more different workers are loaded over time? It seems like we would need some sort of eviction mechanism for these? |
Never mind, I didn't get that this is for built-in modules only. This makes tons of sense for built-ins. |
Yeah, I have no intention of using this for worker bundles for the time being. |
6ba1d7f
to
d73efd5
Compare
4db166c
to
dbd18ce
Compare
983ad7f
to
a423774
Compare
dbd18ce
to
8f21c0c
Compare
ced1492
to
23a4327
Compare
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.
Code LGTM, don't forget to squash fixups.
0d2ccfc
to
898180d
Compare
Builds on #201 which would need to land firstImplements a per-process cache for compiled built-in js/ts modules aimed at reducing the peformance impact of loading those repeatedly across many isolates.
This is purely experimental right now so this PR will remain as a draft for the time being.