Java is fast, code might not be • Hacker News Board

Re: Java is fast, code might not be

#121

Post by [deleted] » Fri, Mar 20, 2026, 6:45 PM UTC

ivan_gammel wrote: post #106

cmovq wrote: post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

TBH, I do not see how Java as a language steers anyone to use one those shotguns. E.g. the knowledge about algorithmic complexity is foundational, the StringBuilder is junior-level basic knowledge.

[deleted]

Re: Java is fast, code might not be

#122

Post by pythonaut_16 » Fri, Mar 20, 2026, 6:55 PM UTC

belfthrow wrote: post #100

pythonaut_16 wrote: post #66

Earlier quoted context omitted.

Can you provide any examples or evidence of Java apps that prove this? Because in my experience as of 2026, Java programs are consistently among the most painful or unpleasant to interact with.

Crac / aot cache / ready now all can address this. Not even considering native aot. Multiple low latency trading systems across market markers, hedge funds and ibs prove this. But people just want to compare it to building a cli tool in go or rust.

But like can you provide an actual example of an application?

> But people just want to compare it to building a cli tool in go or rust.

This seems like the key. HN is definitely biased towards simpler, smaller tools. (And that's not a bad thing!). The most compelling JVM stories I hear are all from much larger scale enterprise settings.

Kafka being a good example. It's very good at what it does, but painful to manage and usually not worth the pain for anyone who's not in a mega enterprise.

Re: Java is fast, code might not be

#123

Post by d_burfoot » Fri, Mar 20, 2026, 6:59 PM UTC

cmovq wrote: post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

> So just manual memory management with extra steps

This is actually the perfect situation: you are allowed to do it carefully and manually for 1% of code on the hot path, but you don't have to worry about it for the 99% of the code that's not.

Re: Java is fast, code might not be

#124

Post by seu » Fri, Mar 20, 2026, 7:01 PM UTC

I'm a bit surprised to see those examples, because there's nothing really new here. These are typical beginner pitfalls and have been there for at least a decade or more. Or maybe it's because I learned java in the late 90s and later used it for J2ME, and then using things like StringBuilder (StringBuffer in the old days) were almost mandatory, and you would be very careful trying to avoid unnecessary object allocations.

Re: Java is fast, code might not be

#125

Post by devnotes77 » Fri, Mar 20, 2026, 7:05 PM UTC

cmovq wrote: post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

[dead]

Re: Java is fast, code might not be

#126

Post by yunnpp » Fri, Mar 20, 2026, 7:10 PM UTC

polothesecond wrote: post #64

wood_spirit wrote: post #50

A subject close to my heart, I write a lot of heavily optimised code including a lot of hot data pipelines in Java. And aside from algorithms, it usually comes down to avoiding memory allocations. I have my go-to zero-alloc grpc and parquet and json and time libs etc and they make everything fast. It’s mostly how idiomatic Java uses objects for everything that makes it slow overall. But eventually after making a JVM…

> And aside from algorithms, it usually comes down to avoiding memory allocations. I’ve heard about HFT people using Java for workloads where micro optimization is needed. To be frank, I just never understood it. From what I’ve seen heard/you have to write the code in such a way that makes it look clumsy and incompatible with pretty much any third party dependencies out there. And at that point, why are you even usin…

I am very interested about this and would like an authoritative answer on this. I even went as far as buying some books on code optimization in the context of HFT and I was not impressed. Not a single snippet of assembly; how are you optimizing anything if you don't look at what the compiler produces?

But on Java specifically: every Java object still has a 24-byte overhead. How doesn't that thrash your cache?

The advice on avoiding allocations in Java also results in terrible code. For example, in math libraries, you'll often see void Add(Vector3 a, Vector3 b, Vector3 our) as opposed to the more natural Vector3 Add(Vector3 a, Vector3 b). There you go, function composition goes out the window and the resulting code is garbage to read and write. Not even C is that bad; the compiler will optimize the temporaries away. So you end up with Java that is worse than a low-level imperative language.

And, as far as I know, the best GC for Java still incurs no less than 1ms pauses? I think the stock ones are as bad as 10ms. How anyone does low-latency anything in Java then boggles my mind.

Re: Java is fast, code might not be

#127

Post by larsnystrom » Fri, Mar 20, 2026, 7:11 PM UTC

seu wrote: post #124

I'm a bit surprised to see those examples, because there's nothing really new here. These are typical beginner pitfalls and have been there for at least a decade or more. Or maybe it's because I learned java in the late 90s and later used it for J2ME, and then using things like StringBuilder (StringBuffer in the old days) were almost mandatory, and you would be very careful trying to avoid unnecessary object allocati…

I remember writing Java for our introductory programming course at university around 2010. I was already familiar with object oriented programming in PHP at the time, so I just wrote the Java code like I would write PHP. I was absolutely astounded at the poor performance of the Java app. I asked one of our tutors and I can still remember him looking at the code and saying something along the lines of ”oh, you’re instantiating objects in a loop, that’s obviously going to be slow”. Like, what? If I can do this performantly in freakin PHP, how can Java, the flagship of OOP, not have fast instantiation of objects? I’m still shaking my head thinking about it.

Re: Java is fast, code might not be

#128

Post by deepsun » Fri, Mar 20, 2026, 7:17 PM UTC

Okx wrote: post #82

The code: public int parseOrDefault(String value, int defaultValue) { if (value == null || value.isBlank()) return defaultValue; for (int i = 0; i Is probably worse than Integer.parseInt alone, since it can still throw NumberFormatExceptions for values that overflow (which is no longer handled!). Would maybe fix that. Unfortunately this is a major flaw in the Java standard library; parsing numbers shouldn't throw exp…

And it will fail with "-"

Re: Java is fast, code might not be

#129

Post by vincnetas » Fri, Mar 20, 2026, 7:18 PM UTC

ackfoobar wrote: post #117

liampulles wrote: post #21

Understanding algorithmic complexity (in particular, avoiding rework in loops), is useful in any language, and is sage advice. In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of inde…

> ditch ORMs ... make good use of SQL I think Java (or other JVM languages) are then best positioned, because of jooq. Still the best SQL generation library I've used.

thumbs up for jooq

Re: Java is fast, code might not be

#130

Post by laughing_man » Fri, Mar 20, 2026, 7:20 PM UTC

cmovq wrote: post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

Java doesn't steer you into object pools. I wrote Java code for 20 years and never used a cache to avoid allocating objects, and never saw a colleague use one. The person you were talking to doesn't know what he's doing.