The feature I was referring to is described here: https://github.com/v8/v8/blob/b4bfbce6f91fc2cc72178af42bb3172c5f5eaebb/include/v8.h#L1625-L1629

This will become more accessible after we replace libdeno with rusty-v8. We should also solve #1692 before attempting this.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@lucacasonato and I discussed this today. Besides required rusty_v8 bindings, we might have to change some types passed to deno_core, but other than that there are no blockers for this feature.

Any update on that ?

It simply hasn't been a priority. The investment is high and the likely improvement in performance is questionable. While there are no blockers for it, there is a lot of other higher priority work for the core team.

Would be great to see some progress on this issue.

Out of interest, what are your usecases @Ayfri and @cunev?

@cunev We are always happy to take PRs from third party contributors if this is something you are interested in!

Just for curiousity in my case !

@lucacasonato In my case anything that can reduce startup time is welcome. In Dropserver [1] I run one Deno instance per app instance, and it gets shut off when the app instance is not in use (to free up resources). This means sometimes I have to start up an instance on an incoming HTTP request. As a result, the faster the startup time, the better.

It's not clear from the comments above how much this feature might help startup time, but if it can, I'm all for it.

Thanks!

[1] https://github.com/teleclimber/Dropserver

@lucacasonato
Code caching would significantly reduce the instantiation time of the "compiled" Deno projects, and act as a small layer of protection for production apps.

Even tho, not a proper way of protecting the code, as long as there is no public V8 bytecode disassembler - it's a great feature to have.
ex. https://github.com/bytenode/bytenode. (result of this discussion)

@lucacasonato not having to unzip the js to the user cache directory would make it easy to install cli deno apps as root that can be used by regular users. Right now we have to define an explicit cache dir.

Bundling the bytecode might also speed up thins for CLI apps.

as long as there is no public V8 bytecode disassembler

There is. But for V8, bytecode is internal and changes based on different versions, so you could potentially need to have unique disassemblers for every version.

We automatically use V8 code cache since 1.43 now (https://deno.com/blog/v1.43#faster-es-and-commonjs-module-loading).