-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
src: stop copying code cache, part 2 #47958
Conversation
Review requested:
|
This removes more copies of the code cache data. First: for the builtin snapshot, we were copying the code cache to create a `std::vector<uint8_t>`. This was slowing down static intialization. Change it to use a good old `uint8_t*` and `size_t` rather than a vector. For the case of embedder provided snapshots, we also add an `owning_ptr` so that we can properly cleanup owned values created from the snapshot. Second: whenever the code cache was hit, we would remove the bytecode from the code cache, and then reserialize it from the compiled function. This was pretty slow. Change the code so that we can reuse the same code cache multiple times. If the code cache is rejected (say, because the user added V8 options), then we need to generate the bytecode, in which case we again use `owning_ptr` to ensure that the underlying code cache is freed. Combined, these changes improve the misc/startup.js benchmarks significantly (p < 0.001): * process,benchmark/fixtures/require-builtins: 22.15% * process,test/fixtures/semicolon: 8.55% * worker,benchmark/fixtures/require-builtins: 26.52% * worker,test/fixtures/semicolon: 21.52%
ab7ac94
to
b43e828
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.
Nice find, I think the generation logic came from a time when we didn't generate the code cache at build time (we always generated the code cache so that workers can reuse the cache compiled by the main thread), but it's obsolete now that we pre-generate the code cache at build time..
Landed in 3ef17b6 |
This removes more copies of the code cache data. First: for the builtin snapshot, we were copying the code cache to create a `std::vector<uint8_t>`. This was slowing down static intialization. Change it to use a good old `uint8_t*` and `size_t` rather than a vector. For the case of embedder provided snapshots, we also add an `owning_ptr` so that we can properly cleanup owned values created from the snapshot. Second: whenever the code cache was hit, we would remove the bytecode from the code cache, and then reserialize it from the compiled function. This was pretty slow. Change the code so that we can reuse the same code cache multiple times. If the code cache is rejected (say, because the user added V8 options), then we need to generate the bytecode, in which case we again use `owning_ptr` to ensure that the underlying code cache is freed. Combined, these changes improve the misc/startup.js benchmarks significantly (p < 0.001): * process,benchmark/fixtures/require-builtins: 22.15% * process,test/fixtures/semicolon: 8.55% * worker,benchmark/fixtures/require-builtins: 26.52% * worker,test/fixtures/semicolon: 21.52% PR-URL: #47958 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Minwoo Jung <nodecorelab@gmail.com>
This removes more copies of the code cache data.
First: for the builtin snapshot, we were copying the code cache to create a
std::vector<uint8_t>
. This was slowing down static intialization. Change it to use a good olduint8_t*
andsize_t
rather than a vector. For the case of embedder provided snapshots, we also add anowning_ptr
so that we can properly cleanup owned values created from the snapshot.Second: whenever the code cache was hit, we would remove the bytecode from the code cache, and then reserialize it from the compiled function. This was pretty slow. Change the code so that we can reuse the same code cache multiple times. If the code cache is rejected (say, because the user added V8 options), then we need to generate the bytecode, in which case we again use
owning_ptr
to ensure that the underlying code cache is freed.Combined, these changes improve the misc/startup.js benchmarks significantly (p < 0.001):