execute virtual ops module on startup if need ops bindings #1014
Conversation
| @@ -1178,7 +1178,7 @@ impl JsRuntime { | |||
| // skip_op_registration: true | |||
| // } | |||
| // ) { | |||
| if init_mode == InitMode::New { | |||
| if init_mode.needs_ops_bindings() { | |||
There was a problem hiding this comment.
I don't think this will work sadly - this will incur additional overhead on each startup because the bindings that are in the snapshot will be overwritten with new bindings each time.
There was a problem hiding this comment.
hmm i was hoping it would be small enough since it only affects deno test/bench/jupyter, but it does look like it slows down deno test startup by about 10% which isn't great.
maybe we could split extensions between ones in the snapshot and ones not in the snapshot, then set up a new virtual ops module with only the ones not in the snapshot?
Like ext:core/ops would be untouched, but for extensions not in the snapshot we would create a new ext:core/extra-ops with those ops?
Not sure it's much better than Deno.core.ops though, hmm
There was a problem hiding this comment.
I think ext:core/extra-ops would work, but that would require us to keep track which ops are already in the snapshot and which were added as "extras" (maybe we already do that, I don't really remember 😬).
I wish we could modify synthethic module (or override it). Maybe @devsnek has any idea how that would be possible.
There was a problem hiding this comment.
maybe you could structure it like having ext:core/ops be an esmodule with a source like export * from 'ext:core/snapshot-ops'; export * from 'ext:core/extra-ops';? Then you have one module which you can populate at snapshot time and another you can populate at runtime, and both are exposed as one.
This doesn't affect e.g. deno run (which has all of its bindings in the snapshot), but allows commands like jupyter,bench,test to use ops from
ext:core/opseven though they aren't in the snapshot