Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java is fast, code might not be

jvogel.me

Post reply on HN
Print view View original

181–190 of 259 posts

Re: Java is fast, code might not be

#181

Post by yrxuthst »

yunnpp wrote: post #126
polothesecond wrote: post #64

Earlier quoted context omitted.

> 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 adv…

Modern ZGC guarantees under 1ms pause times, and Azul's pauseless C4 has been around for a while too.

Re: Java is fast, code might not be

#182

Post by kerblang »

ghurtado wrote: post #160
ivan_gammel wrote: post #102

Earlier quoted context omitted.

The answer is simple: model optimized for storage and model designed for processing are two different things. The languages used to describe and query them have to be different.

> The languages used to describe and query them have to be different. Absolutely not. That which is asserted without evidence can be dismissed without evidence.

> Absolutely not.

Can also be dismissed without evidence

Re: Java is fast, code might not be

#183

Post by kerblang »

nightpool wrote: post #140
ivan_gammel wrote: post #106

Earlier quoted context omitted.

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.

How would you handle validating numeric input in a hot path then? All of the solutions proposed in #5 are incomplete or broken, and it stems from the fact that Java's language design over-uses exceptions for error handling in places where an optional value would be much safer and faster.

> Java's language design over-uses exceptions for error handling

No, library authors' design over-uses exceptions. Also refer to people using exceptions to generate 404 http responses in web systems - hey, there's an easy DDOS... This can include some of Java's standard libraries, although nothing springs to mind.

Exceptions are not meant for mainstream happy-path execution; they mean that something is broken. Countless times I have had to deal garbage-infested logs where one programmer is using exceptions for rudimentary validation and another is dumping the resulting stack traces left and right as if the world is coming to end.

It is a problem, but it's an abuse problem, not a standard usage problem.

Re: Java is fast, code might not be

#184

Post by belfthrow »

pythonaut_16 wrote: post #122
belfthrow wrote: post #100

Earlier quoted context omitted.

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 manag…

Because in real life, real world applications software is large, long running and needs to be bulletproof. Clis are not powering the world's infrastructure via piped bash scripts. It really baffles me what people actually do as software engineers on here with some of the nonsense that gets thrown around.

Re: Java is fast, code might not be

#185

Post by gf000 »

cogman10 wrote: post #78
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…

Bad idea. I've made a pool allocator before, but that was for expensive network objects and expensive objects dealing with JNI. Doing it to avoid memory pressure generally means you simply have a bad algorithm that needs to be tweaked. It's very rarely the right solution.

Not sure why you are down voted. Depending on how its used it could actually be detrimental to performance.

The JVM may optimize many short lived objects better than a pool of objects with less reasonably lifetimes.

Re: Java is fast, code might not be

#186

Post by mike_hearn »

xigoi wrote: post #99
philipwhiuk wrote: post #86

Earlier quoted context omitted.

ORMs are a caching layer for dev time. They store up conserved programming time and then spend it all at once when you hit the edge case. If you never hit the case, it's great. As soon as you do, it's all returned with interest :)

The question is why we don’t have database management systems that integrate tightly with the progmming language. Instead we have to communicate between two different paradigms using a textual language, which is itself inefficient.

https://permazen.io/ exists and is a simpler yet still very powerful way to think about databases (for java but the concepts are general).

But it's only really efficient if it can run code right next to the data via fast access - ideally the same machine. The moment you have a DB running on separate hardware or far away from the client, it's going to be slower.

SQL is a very compact way to communicate what you want from a complex database in a way that can be statically analyzed and dynamically optimized. It's also sandboxable. Not so easily to replace.

Re: Java is fast, code might not be

#187

Post by mike_hearn »

brabel wrote: post #103
spankalee wrote: post #89

Avoiding Java's string footguns is an interesting problem in programming languages design. The String.format() problem is most immediately a bad compiler and bad implementation, IMO. It's not difficult to special-case literal strings as the first argument, do parsing at compile time, and pass in a structured representation. The method could also do runtime caching. Even a very small LRU cache would fix a lot of commo…

Yeah, Java is pretty fast despite the fact that it still has these kinds of obviously suboptimal things going on. I love how Zig, D and Rust do exactly what you say: parse the format string at compile time, making it super efficient at runtime (no parsing, no regex, just the optimal code to get the string you need). I say this but I write most of my code in Java/Kotlin :D . I just wish I could write more low-level la…

Kotlin string interpolation turns into the fancy invokedynamic based string concatenation behind the scenes so it's very optimized: https://openjdk.org/jeps/280

Re: Java is fast, code might not be

#188

Post by computerdork »

EricRiese wrote: post #150

This is a Spring specific gripe and I know this blog post doesn't assume Spring, but I hate seeing `new ObjectMapper()`. Spring Boot auto configures an ObjectMapper for you and you probably want the customization it gives you, including `java.time` handling and classpath scanning. I've wrestled with so many bugs caused by not using the `ObjectMapper` bean.

Have always really liked Java, but yeah, Spring overall has been terrible for the language. Autowiring is against the principles of a typesafe programming language - Don't make me guess what what object is going to be attached to a reference. And if you do, at least figure out what linked object is at compile time, not at run time.

Spring autowiring makes Java seem as a whole unnecessarily complex. Think it should be highly discouraged in the language (unless it is revamped and made apart of the compiler).

... not sure how this applies to the ObjectMapper, as I haven't programmed in Java in awhile. ... and my gripe doesn't apply to SpringBoot though:)

Re: Java is fast, code might not be

#189

Post by inglor_cz »

zmmmmm wrote: post #164

String concatenation in a loop is a 1990's era Java footgun. It's interesting the things that have persisted vs been cast aside. Very significant design decisions have been enforced on far less grounds than the stupidity of how the default String concatenation operator works.

This. I learnt Java in 2004-5, when 1.4 was dominant and O'Reilly books were a much better training resource than whatever you found on the Internet.

Concatenating of thousands of individual Strings was already considered a well-known performance killer back then.

Interesting to see this in the wild in 2026.

Re: Java is fast, code might not be

#190

Post by kykat »

spankalee wrote: post #179
kykat wrote: post #162

Earlier quoted context omitted.

V8 automatically optimizes objects with the same shape into efficient structs, making array of objects much more efficient than in Java. And the manually manager int array acts more like system memory, it's not continuous, so you could have point i 0 and 2 and the data would be: [1, 2, 3, x, x,x, 3, 2, 1] (3D points). So I am not describing a struct of arrays.

Hidden class optimizations just make JavaScript objects behave a little more like Java class instances, where the VM knows where to find each field, rather than having to look it up like a map. It doesn't make JS faster than Java, it makes it almost as fast in some cases.

I can only say what I observed in testing, and that's that having millions of instances of a class like Point3D{x, y, z} in JS uses significantly less memory than in Java (this was tested on Android, not sure if relevant). It was quite some time ago so I don't remember the details.
Post reply on HN