|
|
|
|
|
|
by bloomthrowaway
2904 days ago
|
|
|
A lot of Javascript's optimizations are fragile, as in they don't always hold true, so there's overhead determining if the assumptions still apply. For instance, Javascript's hidden class optimizations are disabled as soon as someone "breaks" the assumption by doing something like accessing a variable using a dynamic array index rather than dot notation. Javascript runtimes also try to infer types as you say based on how objects are used, but this is also a fragile optimization. For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so. Those programs might not represent a real workload but TechEmpower's framework benchmarks are closer. https://www.techempower.com/benchmarks/#section=data-r16&hw=... On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework. And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead. |
|
|
This is definitely not true.
> For instance, if you use an assumed "int" in a string-like way the runtime re-assigns the tagged type. And it's hard to know whether you (or the library you're using) does so.
Also not true - if you assign an integer to a string the engine will still use optimized code - the caveat is different and in megamorphic functions - if your function can accept lots of types that's problematic.
> On most of those benchmarks the fastest JS framework is ~5X slower than the fastest Java framework.
All of those benchmarks are dependent on the underlying library and not the language at all.
> And yeah the array optimizations are related to what we both mentioned above, but again the optimization is not durable. It only works sometimes, and incurs its own overhead.
That's not really how a JIT works and Java is also a JITd language on some runtimes (and the same person wrote both JITs originally - Lars Bak). The overhead is constant and low for the optimizations. The Java JIT compiler does a ton of such assumptions and bailouts as well to elide creating and allocating objects.