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

191–200 of 259 posts

Re: Java is fast, code might not be

#191

Post by computerdork »

dionian wrote: post #32
jayd16 wrote: post #22

Earlier quoted context omitted.

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

LLMs take the whole argument away. Yes, maven/gradle/sbt suck to work with. But now you can just generate it.

Actually, I like Maven. It's perfect for code that is broken into medium-sized projects, which makes it great for service-oriented architectures (would have said microservices here instead, but think we're learning that breaking our services too finely down is generally not a good idea).

Yeah, it seems like Maven is designed to build just one project with relatively little build-code (although, figuring out versioning of the libs used in your build can get tricky, but guessing this is how it is in most languages). It's still one of my favorites build tools for many situations.

Re: Java is fast, code might not be

#192

Post by computerdork »

piva00 wrote: post #8
koakuma-chan wrote: post #2

As much as I love Java, everybody should just be using Rust. That way you are actually in control, know what's going on, etc. Another reason specifically against Java is that the tooling, both Maven and Gradle, still stucks.

Gradle does suck, it gives too much freedom on a tool that should be straightforward and actively design to avoid footguns, it does the opposite by providing a DSL that can create a lot of abstractions to manage dependencies. The only place I worked where the Gradle configuration looked somewhat sane had very strict design guidelines on what was acceptable to be in the Gradle config. Maven on the other hand, is just…

Just wrote a comment how I've always liked Maven. It's perfect for small and medium sized projects, and for service-oriented architectures/microservices - it seems like it was designed for this! It's main goal is to help you figure out the libraries that you're using and build them in a standard way.

It isn't great for really strange and odd builds, but in that case, you should probably be breaking your project down into smaller components (each with it's own maven file) anyways.

Re: Java is fast, code might not be

#193

Post by IsTom »

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.

Does Java not have some kind of helper function to join strings? Why'd anyone write loops like that?

Re: Java is fast, code might not be

#194

Post by computerdork »

jayd16 wrote: post #22
koakuma-chan wrote: post #2

As much as I love Java, everybody should just be using Rust. That way you are actually in control, know what's going on, etc. Another reason specifically against Java is that the tooling, both Maven and Gradle, still stucks.

Not knowing what's going on in Java is a personal problem. The language and jvm have its own quirks but it's no less knowable than any other compiler optimized code. The debugging and introspection tooling in Java is also best in class so I would say it's one of the more understandable run times. Gradle does suck and maven is ok but a bit ugly.

Actually, really like maven, it's focus on building in standard way is fantastic (but agreed, it look messy, with all its xml and necessary versioning).

Re: Java is fast, code might not be

#195

Post by cogman10 »

gf000 wrote: post #185
cogman10 wrote: post #78

Earlier quoted context omitted.

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.

This is the second time this week on HN that I've seen people suggesting object pools to solve memory pressure problems.

I generally think it's because people aren't experienced with diagnosing and fixing memory pressure. It's one of the things I do pretty frequently for my day job. I'm fortunate enough to be the "performance" guy at work :).

It'll always depend on what the real issue is, but generally speaking the problem to solve isn't reinventing garbage collection, but rather to eliminate the reason for the allocation.

For example, a pretty common issue I've seen is copying a collection to do transformations. Switching to streams, combining transformation operations, or in an extreme case, I've found passing around a consumer object was the way to avoid a string of collection allocations.

Even the case where small allocations end up killing performance, for example like the autoboxing example of the OP, often the solution is to either make something mutable that isn't, or to switch to primitives (Valhalla can't come soon enough).

Heck, sometimes even an object cache is the right solution. I've had good success reducing the size of objects on the heap by creating things like `Map` and then doing a `map.computeIfAbsent(str, Function.identity());` (Yes, I know about string interning, no I don't want these added to the global intern cache).

Regardless, the first step is profiling (JFRs and heap dumps) to see where memory is spent and what is dominating the allocation rate. That's a first step that people often skip and jump straight to fixing what they think is broken.

Re: Java is fast, code might not be

#196

Post by wiseowise »

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…

> At that point why not use a better language for the task?

Such as?

Re: Java is fast, code might not be

#197

Post by nitwit005 »

chopin wrote: post #136
laughing_man wrote: post #133

Earlier quoted context omitted.

I've always found ORMs to be performance killers. It always worked out better to write the SQL directly. The idea that you should have a one-to-one correspondence between your data objects and your database objects is disastrous unless your data storage is trivial.

I worked with ORM (EclipseLink) and used SQL just fine. When using JDBC I found myself quickly in implementing a poor mans ORM.

The issue of creating a DB wrapper doesn't go away by using an ORM. One of the complaints about ORMs I have, in practice, is people often create another wrapper around it.

Re: Java is fast, code might not be

#198

Post by lern_too_spel »

kykat wrote: post #162
lern_too_spel wrote: post #161

Earlier quoted context omitted.

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.

"Efficient structs" in v8 are just inefficient Java classes. https://www.dashlane.com/blog/how-is-data-stored-in-v8-js-en...

The optimization you discussed for GIS data is called struct of arrays. JavaScript does not do that automatically for you. You would have to do the same thing manually in JavaScript to avoid per-triple object overhead.

Re: Java is fast, code might not be

#199

Post by laughing_man »

nitwit005 wrote: post #197
chopin wrote: post #136

Earlier quoted context omitted.

I worked with ORM (EclipseLink) and used SQL just fine. When using JDBC I found myself quickly in implementing a poor mans ORM.

The issue of creating a DB wrapper doesn't go away by using an ORM. One of the complaints about ORMs I have, in practice, is people often create another wrapper around it.

I saw that a lot, too. I remember one project using Hibernate where the people involved decided to keep the Hibernate objects "pure" and then had them all wrapped in another object they used to keep information that didn't go into the database.

The whole project must have had 3x the number of classes that the actual complexity required, and keeping it all straight was something of a headache. As was onboarding new people, who always struggled with Hibernate.

Re: Java is fast, code might not be

#200

Post by Mawr »

gmueckl wrote: post #167
fzeindl wrote: post #146

Earlier quoted context omitted.

> 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. autobox…

> Parts of the GC language crowd in particular have come to hold some false optimistic beliefs about how well a GC can handle allocations.

Yep, the idea is "we've made allocations fast, so allocate away!". But that's a trap — every allocation puts pressure on the GC, no matter how fast you've made the very act of allocating. It's a terrible mindset to encourage the users of your language to have.

Then there's the more insidious problem — to make allocations fast you must have traded something off, like GC throughput. So now your GC is slower and encourages programmers to allocate, which makes it even slower.

Post reply on HN