> Why can't we embed a lightweight interpreter such as QuickJS?
> @Ronsor #14404 (comment)
The linked comment [2]:
> @dirkf This solution was tested with QuickJS which yielded execution times of >20 minutes per video
How on earth can it be that terrible compared to Deno?
[1] https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3...
[2] https://github.com/yt-dlp/yt-dlp/issues/14404#issuecomment-3...
QuickJS uses a bytecode interpreter (like Python, famously slow), and is optimised for simplicity and correctness. Whereas Deno uses a JIT compiler (like Java, .NET and WASM). Deno uses the same JIT compiler as Chrome, one of the most heavily-optimised in the world.
That doesn't normally lead to such a large factor in time difference, but it explains most of it, and depending on the type of code being run, it could explain all of it in this case.
QuickJIT (a fork of QuickJS that uses TCC for JIT) might yield better results, but still slower than Deno.
[^1]: https://v8.dev/blog/jitless
[^2]: https://docs.deno.com/runtime/getting_started/command_line_i...
In my mind, an acceptable time for users might be 30 seconds (somewhat similar to watching an ad). If QuickJS is taking >20 minutes, then it is some 40x slower? Seems very high?
> QuickJIT (a fork of QuickJS that uses TCC for JIT) might yield better results, but still slower than Deno.
Interesting, not come across it before. Running C code seems like an insane workaround from a security perspective.