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

161–170 of 259 posts

Re: Java is fast, code might not be

#161

Post by lern_too_spel »

kykat wrote: post #157
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…

I saw something like that being suggested when working with GIS data with many points as classes in Java, the object overhead for storing XYZ doubles is quite crazy. The optimization was to build a global double array and use "pointers" to get and set the number in the array. Even JavaScript is much better for this, much, much better.

You're describing array of structs vs. struct of arrays. Even in JavaScript, you would have to manually do the latter.

Re: Java is fast, code might not be

#162

Post by kykat »

lern_too_spel wrote: post #161
kykat wrote: post #157

Earlier quoted context omitted.

I saw something like that being suggested when working with GIS data with many points as classes in Java, the object overhead for storing XYZ doubles is quite crazy. The optimization was to build a global double array and use "pointers" to get and set the number in the array. Even JavaScript is much better for this, much, much better.

You're describing array of structs vs. struct of arrays. Even in JavaScript, you would have to manually do the latter.

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.

Re: Java is fast, code might not be

#163

Post by pregnenolone »

Java really isn't fast unless you're basically writing C style Java. Abstracting is expensive in Java and if one can't abstract, what's the point of writing Java in 2026? After all these years value types aka Valhalla are still in a soon™ state. If it weren't for Project Loom, which is genuinely awesome, I wouldn’t see any justification for using Java in this day and age.

Re: Java is fast, code might not be

#164

Post by zmmmmm »

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.

Re: Java is fast, code might not be

#165

Post by fnord77 »

pregnenolone wrote: post #163

Java really isn't fast unless you're basically writing C style Java. Abstracting is expensive in Java and if one can't abstract, what's the point of writing Java in 2026? After all these years value types aka Valhalla are still in a soon™ state. If it weren't for Project Loom, which is genuinely awesome, I wouldn’t see any justification for using Java in this day and age.

The world has shown that it doesn't need all those intricate design patterns that java fosters.

It does seem like java missed their chance, it's a shame.

Re: Java is fast, code might not be

#166

Post by jimbokun »

pregnenolone wrote: post #163

Java really isn't fast unless you're basically writing C style Java. Abstracting is expensive in Java and if one can't abstract, what's the point of writing Java in 2026? After all these years value types aka Valhalla are still in a soon™ state. If it weren't for Project Loom, which is genuinely awesome, I wouldn’t see any justification for using Java in this day and age.

Compared to what?

Re: Java is fast, code might not be

#167

Post by gmueckl »

fzeindl wrote: post #146
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…

> a lot of real world performance comes down to how efficiently you are calling external services (including the database) Apart from that my experience over the last 20 years was that a lot of performance is lost because of memory allocation (in GCed languages like Java or JavaScript). Removing allocation in hot loops really goes a long way and leads to 10 or 100 fold runtime improvements.

This applies to non-GC languages as well. Memory management is slow. Even with manual memory management I have been able to dramatically speed up code simply by modifying how memory is allocated.

Parts of the GC language crowd in particular have come to hold some false optimistic beliefs about how well a GC can handle allocations. Also, Java and C# can sneak in silly heap allocations in the wrong places (e.g. autoboxing). So there is a tendency for programs to overload the GC with avoidable work.

Re: Java is fast, code might not be

#168

Post by dionian »

ivan_gammel wrote: post #153
nightpool wrote: post #148

Earlier quoted context omitted.

Okay, but this contradicts your original statement that "Java doesn't steer anyone to use these [footguns]". Every language has a way to parse integers, and most developers do not need a custom parser. Only in Java does that suddenly become a performance footgun.

It does not. If you need to parse a number, you use standard library and you will be fine. The described case with huge impact on hot path is the demonstration why using brains is important. The developer that will get into this mess is the one who will find the way to suffocate his code with performance bottlenecks in thousand other ways. It’s not a language or library problem.

Yes, parseInt et al work very fast for good inputs. What percentage of your inputs are invalid numbers and why ?

Re: Java is fast, code might not be

#169

Post by dionian »

pregnenolone wrote: post #163

Java really isn't fast unless you're basically writing C style Java. Abstracting is expensive in Java and if one can't abstract, what's the point of writing Java in 2026? After all these years value types aka Valhalla are still in a soon™ state. If it weren't for Project Loom, which is genuinely awesome, I wouldn’t see any justification for using Java in this day and age.

my hotspot JITd code is quite fast

Re: Java is fast, code might not be

#170

Post by dionian »

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.

well yeah Jackson is slow.
Post reply on HN