>Slowness isn't a property of the language it's a property of the runtime
This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.
Language design choices have a huge effect on how fast the runtime can be. In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed. This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.
You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
Except for one benchmark, where memory requirements are likely determined by the implemented algorithm, Java consumes in order of magnitude more memory across the board.
Other benchmarks from the same group do show the memory usage and both node and Java are quite bad, as expected. Node is spectacularly bad at some, using 1.8 GB vs Java's 384M or C++'s 155M for example.
Java's usage will never compare to compiled languages without GC because it has to cache a bunch of code in RAM and the garbage builds up between collection cycles. It's pretty bad compared to something like C for sure :)
> This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.
PHP7 isn't a slow language at all - it's much faster than previous versions actually. There are servers like aerys [1] that easily handle 10,000 concurrent requests on reasonable hardware. The reason sapi (read "regular") PHP isn't "faster" is because caching and the ease of deploying more servers makes it less of a priority to stakeholders.
Like I said - this is more dependent on the libraries used than the language.
> In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed.
This is also not true - JavaScript objects are stored through a technique called "hidden classes" akin to a C like struct in most modern runtimes [2].
> This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work.
This is also false, JIT engines store run time information about the object (see hidden classes above [2]) and use that to optimize by type. V8 does this a lot and monomorphic functions are much faster [3]. Inline caches (ICs) really help there.
> It's slower than java on every test.
All those programs are poorly written and are running outdated versions of both Java and Node.js. Moreover they do not represent a workload people have in any reasonable way. I think that regardless it is possible Java is faster in a lot of workloads. I wouldn't use Java nor Node.js for any of the above programs there.
> Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed.
See [2] and [3] - that's not how it works.
> In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.
V8 has explicit handling for arrays of SMIs (small integers) with bailout semantics. JavaScript runtimes figure this out - feel free to ask for V8 source references. Also see my answer here on a library I maintain (bluebird) https://stackoverflow.com/a/24989927/1348195
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.
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.
> 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.
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.
This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.
Language design choices have a huge effect on how fast the runtime can be. In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed. This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.
You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.