new | show | ask | jobs Github

bArray 3 days ago

Ronsor [1] and reply by seproDev:

> 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...

▲

jlokier 3 days ago | parent | next [-]

> How on earth can it be that terrible [>20 minutes] compared to Deno?

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.

▲

ynx 3 days ago | parent | next [-]

JIT is still banned by policy on a LOT of mobile devices, meaning that previous usage of yt-dlp on mobile is now effectively unsupportable.

▲

SpaghettiCthulu 3 days ago | parent | next [-]

I haven't tested this, but in theory running deno with `--v8-flags='--jitless'`[^1][^2] will disable the JIT compiler.

[^1]: https://v8.dev/blog/jitless

[^2]: https://docs.deno.com/runtime/getting_started/command_line_i...

▲

Klonoar 3 days ago | parent [-]

If the performance drops due to lack of JIT, then GPs comment about effectively useless on mobile might still hold weight.

	▲	int_19h 3 days ago \| parent [-]
		It's probably a lot more than that. A well-optimized bytecode interpreter is not 100x slower than native code. But also e.g. QuickJS uses refcounting with the occasional tracing to remove cycles, and while it's a simple and reliable approach, it's not fast.

▲

1317 3 days ago | parent | prev [-]

well yt-dlp would also be banned surely? so it's not an issue anyway

▲

bArray 3 days ago | parent | prev [-]

My concern is either that QuickJS is something like 100x slower, or that even when using Deno, the download experience will be insanely slow.

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.

▲

ronsor 3 days ago | parent | prev | next [-]

It's horrifying and Google must've worked very hard to kill the performance in other interpreters.

	▲	lucianbr 3 days ago \| parent [-]
		The brightest minds (or something close) working hard to make computation slower and more difficult, so that someone can profit more.

▲

darknavi 3 days ago | parent | prev [-]

That is interesting. We use QuickJS in Minecraft (Bedrock, for modding) and while it's much slower than V8 it's not _that_ much slower.