mujs performance improvement or support quickjs

[ahaoboy]

Expected behavior of the wanted feature

Mujs is a JavaScript engine designed for small devices, but devices typically used for video playing have sufficient performance, so it's possible to modify some of mujs's compilation parameters to enhance performance.

For example, the 'JS_ASTLIMIT' defaults to 100, some bundlers uses comma expression optimization for size reduction. This can result in code similar to the following directly throwing a 'too much recursion' error.

function f() {
  return 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100;
}

f()

Additionally, the 'REG_MAXCLASS' compilation option defaults to 16, which causes some third-party librarys' regular expressions to fail. 'JS_STACKSIZE' defaults to 256. When executing a bundled large JavaScript file, it often exceeds 1 MB, sometimes leading to direct stack overflow.

Alternative behavior of the wanted feature

Is it possible to support the QuickJS engine? QuickJS supports ES6 syntax and has significantly better performance compared to mujs. To ensure ES5 compatibility, a considerable amount of compatibility work is needed, resulting in increased file size.

[Andarwinux]

Maybe consider some JS engines that support JIT. File size should no longer be a problem these days.

[ahaoboy]

Maybe consider some JS engines that support JIT. File size should no longer be a problem these days.

Here is a comparison of several JavaScript engines. Currently, qjs is quite suitable in terms of both performance and size. As for JIT, there is currently an unofficial implementation available. However, qjs is already sufficiently fast, and JIT might not be necessary.

redis/redis#11128
https://github.com/bnoordhuis/quickjit

[avih]

'JS_ASTLIMIT' defaults to 100
'REG_MAXCLASS' compilation option defaults to 16
'JS_STACKSIZE' defaults to 256

Increasing these will not increase performance. It will only allow bigger programs.

It's unclear if your bottle neck is program size or performance. According to the limits you want raised, it looks to be program size and not actually performance.

mpv has no control over how mujs was configured and built. If you build your own version of mujs then you can change these, or if you use a 3rd party build then you can request them. But mpv is not part of that.

The best thing would be to ask mujs to increase these limits. Limits have been raised in the past, and if there are good reasons (real world use cases), then it would probably be raised.

Here is a comparison of several JavaScript engines

This lists duktape, quickjs, and v8.

v8 was not and is not considered as it's very big.

mpv initially did support both mujs and duktape (quickjs didn't exist when JS was added to mpv), but eventually duktape support was removed because we only needed one engine, and mujs was good enough. Also, mujs is much simpler and cleaner code than duktape, and they're largely on par (duktape is a bit faster, and with a bit more features, but quite more complex).

quickjs is another matter. While embedding mujs or duktape is generally similar (to eachother and to lua), quickjs is a completely different beast.

Few initial attempts to integrate quickjs didn't go well, mainly because integrating it requires a lot more work than embedding lua or mujs or duktape, and there have not been efforts since. Contributions are welcome.

That being said, mujs did and does still hold up reasonably useful. Speed is generally not an issue for mpv scripts (and mujs is not much slower than lua, though luajit can be very fast in some cases), and size limits can be raised if really needed (at the mujs side)

So the bottom line is that the limits can be raised if you ask whoever builds it, or mujs themselves to raise the defaults.

No current plans to integrate v8 (too big), duktape (not enough value), or quickjs (hard, but if someone has the time and ability to work on it, why not).

[ahaoboy]

It's unclear if your bottle neck is program size or performance. According to the limits you want raised, it looks to be program size and not actually performance.

Currently, there are no bottlenecks in terms of size and performance. However, there are some compatibility issues on mujs that render it unusable. For developers, directly writing a 2-3 thousand line program in ES5 syntax is impractical. Generally, developers use bundling tools and third-party libraries. Mujs currently faces certain issues (ccxvii/mujs#180) that demand significant time and effort to polyfill some interfaces. On the other hand, QJS encounters fewer of these problems. Yet, integrating QJS into the MPV project indeed presents a substantial task. I will attempt to adjust the bundling tool's configuration to circumvent these issues.

[Kagami]

duktape is a bit faster

According to Bellard's benchmarks, duktape is 2.5x faster than mujs.

Although QuickJS is 6x faster than MuJS and also supports more ES features, so you don't need to transpile modern features all way down to ES5. No way people would write code in ES5 nowadays, and transpiling/polyfills bring additional overhead, so MuJS takes additional hit in performance.

Another idea I have, is mpv cplugin + V8, similar to how coc.nvim in neovim operates. Not sure if that's easier/better than out-of-the-box QuickJS support but at least you won't have to worry about performance with a fast JS engine.

[ahaoboy]

In the early experimental stage, compatibility and syntax conversion were truly a nightmare. In terms of performance, mujs is indeed the slowest, with the least supported syntax. However, it is also the smallest and easiest to integrate. Integrating qjs or other engines, on the other hand, requires a substantial amount of work, and it is unlikely to be completed in a short period.
The current performance bottlenecks are speculative. During the testing phase, I used over 100 components, and there was some initial delay in rendering, which seems to be related to the overlay creation. However, after the first successful rendering, the delay becomes acceptable for normal usage. The bottlenecks still need to be tested after the layout is completed. Layout management involves a considerable amount of computation, and around 50 elements are probably sufficient for uosc. Hopefully, mujs can meet the requirements.

[avih]

According to Bellard's benchmarks, duktape is 2.5x faster than mujs.

In terms of performance, mujs is indeed the slowest

There were many performance improvements in mujs since that comparison was made some years ago, with several key bottlenecks improved greatly, mainly C-array for simple integer-index arrays instead of string-based (binary tree) index, much faster Array.join, GC which scales with the program size and has much lower overhead than before with big programs (as some of that benchmark tests are), and other imoprovements.

So it's maybe still a bit slower than duktape, but it's roughly in the same ballpark.

Although QuickJS is 6x faster than MuJS

Was back then. I'm guessing the gap is a bit smaller now.

mujs ... with the least supported syntax

It's ES5.1. If you think valid ES5.1 syntax is rejected by mujs, then it's a bug and you should report it. I'm not aware of such issues currently. That trailing comma in function args which was reported recently is not valid ES5.1.

the delay becomes acceptable for normal usage. The bottlenecks still need to be tested after the layout is completed. Layout management involves a considerable amount of computation, and around 50 elements are probably sufficient for uosc. Hopefully, mujs can meet the requirements.

Indeed, that's the bottom line, that it's likely sufficient for the vast majority of mpv scripts.

It could definitely have some bottlenecks with intense computations (as would quickjs, depending on the definition of "intense", where only JIT would bring it meaningfully closer to native performance), but it's largely quite good.

It's not intended compile huge programs into JS, WASM-like, but for normal, human written scripts, it's generally quite sufficient.

[avih]

Also, if any of you need a Promise/A+ implementation which works great in mpv (and for typescript transpiling), try nopromise /shameless-plug.

[Kagami]

There were many performance improvements in mujs since that comparison

Good to know.

It's ES5.1

I think he means that people nowadays write code with features like classes, arrow functions, iterators, async functions, etc. None of this is supported by MuJS, so needs to be transpiled, so performance may be even worse compared to interpreters which support later ES standards.

Promise/A+ implementation

Nice. Also the lack of convenient stdlib functions like
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replaceAll
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/endsWith
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/entries
is a problem.

Seems like people use core-js to polyfill this stuff nowadays, but I looked at the implementation of one of this and it's so bloated... I'm afraid to feed poor little MuJS with that stuff 😄

(Of course if you need just few of those, it's easy to write by hand, I mean when you e.g. port some existing code which uses dozens of them.)

[avih]

needs to be transpiled, so performance may be even worse compared to interpreters which support later ES standards.

Possibly. Feel free to provide some actual numbers.

I think he means that people nowadays write code with features like classes, arrow functions, iterators, async functions, etc

Well, it's ES5.1. Duktape is pretty much the same with few extensions from later versions, but it still only targets full compliance with 5.1. And yes, newer versions of the standard extended the language in many ways.

async/await can transpile to mujs just fine (in mpv, because it requires some async infrastructure, which mpv's js has in the form of compliant setTimeout et al), and very efficiently, if you have a compliant Promise implementation, like nopromise which was mentioned above.

I mean when you e.g. port some existing code which uses dozens of them.

Indeed. Porting big projects to mpv's mujs can be a pain, but then these projects probably target node.js or a browser, and mpv is just not that. So even if the language was big enough to support that (as a transpiler is likely to be able to handle), the context is still different than most packages target originally.

[avih]

For reference, here's detailed instructions for async/await in mpv, written some time ago: #6079 (comment)

[Kagami]

Duktape is pretty much the same

I meant QuickJS which supports ES2020, I think most people should be fine with that. (I understand that it's hard to integrate qjs to mpv.)

Porting big projects to mpv's mujs can be a pain

Not necessary big, could be just a bunch of little npm deps. (But not sure how well they would work, the lack of Node API inside MuJS runtime might be a massive pain point.)

Anyway, I agree, needs testing to see the real world bottlenecks of MuJS.

[avih]

bunch of little npm deps. (But not sure how well they would work, the lack of Node API inside MuJS runtime might be a massive pain point.)

Exactly. mpv is not node.js, as also documented at the mpv JS docs. Some small (ES5.1) self-contained node modules might work as is in mpv, but for the most part, the node.js API and modules are just not there, because it's for mpv scripts, not system/server/general-app scripts...