Why low-latency Java still requires discipline?

Post by whaleofatw2022 » Mon, Jul 06, 2026, 6:29 PM UTC

pjmlp wrote: post #35

__s wrote: post #34

Earlier quoted context omitted.

Yes. & in the end my experience has been that you can write low latency code with gc, but only by expending more effort than it'd take to use manual memory management

First of all it depends on the language, what GC models it supports, and what are the performance SLAs. Secondly if we are talking about something like real time audio, or sending the maximum amount of triangles per second, then there is zero memory management, the code should be allocation free across all the critical path, regardless of the language.

Post by MaxBarraclough » Mon, Jul 06, 2026, 7:12 PM UTC

throwaway894345 wrote: post #42

ecshafer wrote: post #39

Earlier quoted context omitted.

Java is a great language and runtime. Java being slow is most often a pebcak scenario. There are massive, fast, low latency, Java systems out there that have been written by competent developers.

> Java being slow is most often a pebcak scenario Am I the only one who thinks "pebkac" is a self-own? If you're blaming your users for the tool, it feels like maybe your tool is just hard to use properly. I have no doubt that there are big, fast, low latency Java systems out there, but why does it take so much extra effort to build these systems in Java compared with other languages? Maybe it would be better to have…

Post by bluGill » Mon, Jul 06, 2026, 10:19 PM UTC

pretzellogician wrote: post #26

bluGill wrote: post #16

Earlier quoted context omitted.

If low latency is your goal than you don't want JIT. JIT has two issues in low latency, first the first time through your code isn't compiled yet and so you get high latency. Second, it optimizes for the common case, which means when you hit an exception that exception will be higher latency because everything hits a branch miss. Of course we are talking generals here. Sometimes the above is acceptable and Java/JIT i…

Valid points, but this doesn't mean JIT doesn't work for relatively lower-latency coding. To avoid the compilation etc. hit, common practice is to do some "warmups" before serving users. (Another reply has other ways to avoid this hit.) Handling exceptions is higher latency, but they can/should be optimized out, so you're not hitting exceptions as part of your standard workflow (or even your 1% workflow).

Post by Archit3ch » Mon, Jul 06, 2026, 10:30 PM UTC

bluGill wrote: post #16

motoboi wrote: post #9

Earlier quoted context omitted.

Rust? OK. C++ or go? Then you'll have to take a very closer look, because the java JIT is wonderful. A masterpiece of several hands, actually.

If low latency is your goal than you don't want JIT. JIT has two issues in low latency, first the first time through your code isn't compiled yet and so you get high latency. Second, it optimizes for the common case, which means when you hit an exception that exception will be higher latency because everything hits a branch miss. Of course we are talking generals here. Sometimes the above is acceptable and Java/JIT i…

Post by frollogaston » Mon, Jul 06, 2026, 11:22 PM UTC

throwaway894345 wrote: post #42

ecshafer wrote: post #39

Earlier quoted context omitted.

Java is a great language and runtime. Java being slow is most often a pebcak scenario. There are massive, fast, low latency, Java systems out there that have been written by competent developers.

> Java being slow is most often a pebcak scenario Am I the only one who thinks "pebkac" is a self-own? If you're blaming your users for the tool, it feels like maybe your tool is just hard to use properly. I have no doubt that there are big, fast, low latency Java systems out there, but why does it take so much extra effort to build these systems in Java compared with other languages? Maybe it would be better to have…