Hacker News Reader

Comment by MrBuddyCasino | Hacker News Reader

> I mean there is a definite performance gain from Java to Go

I don't think thats true.

There are dramatic memory and startup time improvements. Much less so for CPU once everything is up and running.

Is that still true after tuning the JVM GC for a low memory footprint? I'm genuinely asking, I'd like to see an article on the subject. I've read in the past that the default settings are geared towards long-running processes and trade off memory usage for higher throughput, as in general there's no free lunch with GCs. Better memory usage always implies worse performance (and viceversa), just like a higher throughput increases pause times. If Go has lower memory usage and lower pause times, I'd expect it to have lower throughput than the JVM GC.

There's two more variables you're missing here, besides "memory" and "pause times" - how well matched to GC the language is, and how advanced/good the GC is. Some languages might just be fundamentally easier to garbage collect than others - a simple example might be that of a language with no references and no threading, where the GC is going to be extremely simple. And GC quality is certainly a thing, since I doubt major companies would spend tens/hundreds of millions of dollars producing GC 'advancements' that just move a slider back and forth.

Yes.

Every object in Java has something like three words of overhead; also since it doesn't have value semantics (yet) objects are typically allocated out-of-line, so an ArrayList makes a linear number of allocations, whereas a Go slice makes a constant number. Plus the binary sizes are typically much smaller; not really an expert but our observataion at work is non-trivial Java services allocate a lot of memory through classloading / JITing whereas a Go binary will typically be very small.

Basically, agreed on the GC tradeoff, but the higher memory footprint of Java mostly comes from other areas.

> Better memory usage always implies worse performance

That isn't really true. Better memory usage implies better cache-friendliness (and possibly better locality too).

The GC isn't very good yet, but brute-force sequential code can keep more state on the stack where it doesn't matter. (Just please codegen that instead of expecting everyone to read it.)

Go's GC is better than most of the Java GCs except the new ZGC and Azul's proprietary one. JIT makes some Java code faster. Ultimately, it's more about programmer expertise in a language rather than the actual language.

It's all relative. Go is optimized for pause times and beats all other mainstream runtimes for that. JVM GC is very configurable and can be optimized for throughput, pause times, heap size, fragmentation, or whatever you want, and can beat Go's for pretty much all of them except pause times. Both have very smart people working on them and the techniques are well established, so it's about tradeoffs. (An oldish post but I think still relevant: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...)

That said, Go's focus may be the right one for many use cases. On a high throughput service where you would assume you want to optimize for throughput, 100 ms pause times can wreak havoc because they're unpredictable and can cause work queues to explode and such. This isn't easily mitigated by load balancing. Whereas "less efficient" GC is at least predictable and you can just add a server to balance that extra work.

Reply on news.ycombinator.com