deno
deno copied to clipboard
denoland
perf(core): don't embed source files from extensions
This commit changes how "deno_core::Extension" handles JavaScript source files provided by extension. Before this commit, the sources were always embedded into the binary, even though they are only needed during the build process - during build, the sources are loaded into the runtime and snapshotted. This means that we had two copies of the same source files in the resulting binary, even though the embedded ones were never used. This changes results in ~1Mb smaller binary size, at least on macOS.
JavaScript sources for "webgpu" extension were moved from "ext/webgpu/src/" to "ext/webgpu" so all extensions have consistent file structure.
If I'm understanding this change correctly, this will make any program using deno_core without snapshots non-distributable. Regardless of whether we want even small users of deno_core to rely on snapshots, this would be a huge footgun, especially for first-time deno_core users.
If I'm understanding this change correctly, this will make any program using deno_core without snapshots non-distributable. Regardless of whether we want even small users of deno_core to rely on snapshots, this would be a huge footgun, especially for first-time deno_core users.
Good catch! I will rework it to allow for both cases.
If I'm understanding this change correctly, this will make any program using deno_core without snapshots non-distributable. Regardless of whether we want even small users of deno_core to rely on snapshots, this would be a huge footgun, especially for first-time deno_core users.
Good catch! I will rework it to allow for both cases.
This still doesn't solve the problem, because even if you can choose to make your extensions distributable, 01_core.js will not be. This probably won't be easy to solve, though.
If I'm understanding this change correctly, this will make any program using deno_core without snapshots non-distributable. Regardless of whether we want even small users of deno_core to rely on snapshots, this would be a huge footgun, especially for first-time deno_core users.
Good catch! I will rework it to allow for both cases.
This still doesn't solve the problem, because even if you can choose to make your extensions distributable,
01_core.jswill not be. This probably won't be easy to solve, though.
That's right, was just discussing this with @crowlKats. We'll probably always embed them in the binary, they are quite small after all.
Okay this is now fixed - there's include_js_files! macro that actually embeds the source and include_js_files_from_crate! which doesn't embed the source but reads it from the crate contents and is meant to be used during snapshotting.
We used to do this: #10786
And then Aaron reverted because you all didn't like that you could not portably run without snapshotting anymore: #14614
That's the thing that is blocking this PR ATM, need to come up with mechanism that will work in all different situations (creating a snapshot, creating a snapshot from existing snapshot, running without a snapshot, running with a snapshot).