3 ms·

The picture I'm seeing is that it would seem that they're in the same ballpark, and v8 may even be a smidge faster, for general purpose business object flogging

The picture I'm seeing is that it would seem that they're in the same ballpark, and v8 may even be a smidge faster, for general purpose business object flogging type stuff, but Java is significantly faster for straight-up number crunching. The one where there's the starkest difference, k-nucleotide, Java gets to take advantage of a fastutil collection. I don't think an equivalent to that hash map could be built in JavaScript. Those benchmarks don't cover this, but I wouldn't be at all surprised to discover that Electron can does actual UI drawing more efficiently than Java can. In Electron, that whole layer is a bunch of (presumably) carefully optimized C++ code, while in Java the bulk of it's still going to either be managed code, or be taking a lot of marshalling hits if it's calling into OS APIs. Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway.

pier25 6y ago
I agree. Also, when you look at UI benchmarks for web frameworks replacing/updating thousands of DOM elements per second, I have serious doubts the problem of web-based UIs is performance. I agree Electron is a cancer, but not because it uses web-based UIs, but because every app ships its own version of Node + V8. A couple of years ago I built a cross platform app using the native web view on each platform (WKWebview on macOS/iOS, WebView on UWP, Chrome web view on Android and ChromeOS). The app for macOS was like a 4MB download from the Mac App Store and it consumed like 15-20MB or RAM.
lmm 6y ago
> Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway. The performance of a non-memory-safe language is usually 0; if you don't care about the time to get a correct result rather than just any "result" then why would you use a programming language at all?
- mumblemumble 6y ago
  I don't see much value in that kind of sniping. Especially in a world where C is still the most popular language in domains such as spacecraft control software or operating system kernels where correctness is of the most paramount importance. One doesn't need to meditate on that for very long to realize that choosing a non-memory-safe language is not a decision that correctness is not important, it's simply a decision that the programmer must be personally responsible for yet another aspect of correctness. Also, needing to make a hard choice between "faster than Java" and "memory safe" was a problem for the late 1990s. 20 years later, we have a lot more options.
  - lmm 6y ago
    I've spent a significant proportion of my career working on financial codebases that did serious number crunching in Java and were performance-bounded, and Java was still absolutely the correct choice for those codebases. So the idea that performance is irrelevant for those domains in cases where Java is a reasonable choice is completely wrong. Having the programmer be personally responsible for memory safety doesn't work, we know that now. What spacecraft control software is written in isn't really C any more than typescript is javascript: yes, the final runtime artifact is in C, but the "source code" includes a lot of additional verification material without which it wouldn't be valid. As for operating system kernels, even Linux isn't written in C any more because C is too unsafe; rather it's written in an ad-hoc language that provides stronger safety guarantees (which it compiles by passing special parameters like -fno-delete-null-pointer-checks to GCC).

pier25 6y ago

I agree. Also, when you look at UI benchmarks for web frameworks replacing/updating thousands of DOM elements per second, I have serious doubts the problem of web-based UIs is performance. I agree Electron is a cancer, but not because it uses web-based UIs, but because every app ships its own version of Node + V8. A couple of years ago I built a cross platform app using the native web view on each platform (WKWebview on macOS/iOS, WebView on UWP, Chrome web view on Android and ChromeOS). The app for macOS was like a 4MB download from the Mac App Store and it consumed like 15-20MB or RAM.

lmm 6y ago

> Long story short, it would appear that, based on those benchmarks (which, we all realize benchmarks are a lie, but still) the only spot Java clearly beats JavaScript is in applications where someone who cares all that much about performance would choose neither Java nor JavaScript, anyway. The performance of a non-memory-safe language is usually 0; if you don't care about the time to get a correct result rather than just any "result" then why would you use a programming language at all?

mumblemumble 6y ago
I don't see much value in that kind of sniping. Especially in a world where C is still the most popular language in domains such as spacecraft control software or operating system kernels where correctness is of the most paramount importance. One doesn't need to meditate on that for very long to realize that choosing a non-memory-safe language is not a decision that correctness is not important, it's simply a decision that the programmer must be personally responsible for yet another aspect of correctness. Also, needing to make a hard choice between "faster than Java" and "memory safe" was a problem for the late 1990s. 20 years later, we have a lot more options.
- lmm 6y ago
  I've spent a significant proportion of my career working on financial codebases that did serious number crunching in Java and were performance-bounded, and Java was still absolutely the correct choice for those codebases. So the idea that performance is irrelevant for those domains in cases where Java is a reasonable choice is completely wrong. Having the programmer be personally responsible for memory safety doesn't work, we know that now. What spacecraft control software is written in isn't really C any more than typescript is javascript: yes, the final runtime artifact is in C, but the "source code" includes a lot of additional verification material without which it wouldn't be valid. As for operating system kernels, even Linux isn't written in C any more because C is too unsafe; rather it's written in an ad-hoc language that provides stronger safety guarantees (which it compiles by passing special parameters like -fno-delete-null-pointer-checks to GCC).