4 ms·

In particular areas (short timespans, specific tasks), Java can be thousands of times slower than C++/Rust. (Warmup/pre-JIT function evaluation, GC pauses, etc.

In particular areas (short timespans, specific tasks), Java can be thousands of times slower than C++/Rust. (Warmup/pre-JIT function evaluation, GC pauses, etc.) I have these kinds of performance rough spots, but I'm surprised to hear you do. It doesn't seem consistent with an argument for Java.

scottlamb 6y ago
s/have/hate/
lmm 6y ago
I don't think you'll find a realistic case where Java is thousands of times slower than C++/Rust. You're even less likely to find a case where it's a worse order of asymptotic complexity. Whereas you'll find plenty of cases where (at least 2008-era) SpiderMonkey is in a worse complexity order than V8.
- jolux 6y ago
  Client warmup times are not great. Java is incredibly fast but attempts to write an HTML engine in it in the past didn’t really pan out. Also, WebKit was already written in C++.
- scottlamb 6y ago
  You don't have to look far at all to find such cases. Startup takes forever. It's not that there's a specific small operation that programs in both languages do and is O(log n) in C++ and O(n^2) in Java. It's more that the Java programs do work that is unthinkable with C++. They run an optimizing compiler (once they decide its worthwhile on a given function). That's not something C++ programs do. [1] Until that happens, they may be running completely unoptimized interpreted code. They might go through the whole thing again if they fill their perm gen (or whatever it's called) and evict the optimized version of the code. They run a garbage collector which sometimes stops the world. Your tiny function might have to wait for gigabytes of heap to be scanned. Over sufficiently long runs, throughput is easily within the factor of 2 you mentioned. But over short timescales, thousands of times slower is completely plausible. Some C++ CLI application might run in 5 ms where the equivalent Java program takes 5 seconds. IIRC there was some article recently challenging the assumption that Java programs commonly reach the optimized steady state at all. I can't find it though. [1] Except V8 of course on the user-supplied JavaScript. I'd call that quite different than optimizing all Chrome's own code.
  - lmm 6y ago
    Sorry, I had a longer reply to your previous message that I lost somehow. In the context of something like Chrome that's already willing to implement a custom process model, I don't think that there are business requirements where that kind of large overhead is unavoidable. Running an individual unix-style JVM process can indeed perform very poorly on the default settings. But that's not the only way to build a web browser.
    - jolux 6y ago
      It’s probably doable but I don’t know with what kind of performance envelope. Java famously has very high runtime costs in pathological cases, and it’s very easy to shoot oneself in the foot. I completely agree that memory safety is more important, but it’s not like they wrote a new rendering engine from whole cloth, they used WebKit.

scottlamb 6y ago

s/have/hate/

lmm 6y ago

I don't think you'll find a realistic case where Java is thousands of times slower than C++/Rust. You're even less likely to find a case where it's a worse order of asymptotic complexity. Whereas you'll find plenty of cases where (at least 2008-era) SpiderMonkey is in a worse complexity order than V8.

jolux 6y ago
Client warmup times are not great. Java is incredibly fast but attempts to write an HTML engine in it in the past didn’t really pan out. Also, WebKit was already written in C++.
scottlamb 6y ago
You don't have to look far at all to find such cases. Startup takes forever. It's not that there's a specific small operation that programs in both languages do and is O(log n) in C++ and O(n^2) in Java. It's more that the Java programs do work that is unthinkable with C++. They run an optimizing compiler (once they decide its worthwhile on a given function). That's not something C++ programs do. [1] Until that happens, they may be running completely unoptimized interpreted code. They might go through the whole thing again if they fill their perm gen (or whatever it's called) and evict the optimized version of the code. They run a garbage collector which sometimes stops the world. Your tiny function might have to wait for gigabytes of heap to be scanned. Over sufficiently long runs, throughput is easily within the factor of 2 you mentioned. But over short timescales, thousands of times slower is completely plausible. Some C++ CLI application might run in 5 ms where the equivalent Java program takes 5 seconds. IIRC there was some article recently challenging the assumption that Java programs commonly reach the optimized steady state at all. I can't find it though. [1] Except V8 of course on the user-supplied JavaScript. I'd call that quite different than optimizing all Chrome's own code.
- lmm 6y ago
  Sorry, I had a longer reply to your previous message that I lost somehow. In the context of something like Chrome that's already willing to implement a custom process model, I don't think that there are business requirements where that kind of large overhead is unavoidable. Running an individual unix-style JVM process can indeed perform very poorly on the default settings. But that's not the only way to build a web browser.
  - jolux 6y ago
    It’s probably doable but I don’t know with what kind of performance envelope. Java famously has very high runtime costs in pathological cases, and it’s very easy to shoot oneself in the foot. I completely agree that memory safety is more important, but it’s not like they wrote a new rendering engine from whole cloth, they used WebKit.