Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Java vs. Go performance
11–20 of 69 posts
Re: Java vs. Go performance
#12Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
That comes from the fact that Java takes quite a while to startup. It is going to be hopefully fixed in Java 9 where the platform becomes more modular. But that issue is what caused Java to have such a terrible reputation when apps were run on the desktop.
Re: Java vs. Go performance
#13Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…
As someone who has a fairly strong distaste for Java: It's not unfair at all. If I want to make the most of my CPU, and Java runs faster than Go, then that's the way it is.
There may be historical reasons for this. There may be low hanging fruit for Go. But in the end, all that matters to the consumer of my project is "code go fast?".
Re: Java vs. Go performance
#14Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…
[deleted]
Re: Java vs. Go performance
#15Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Once you heat up the JVM, Java can run like a bat out of hell. And, if you don't run into GC problems, it's as fast as anything out there.
Re: Java vs. Go performance
#16I find these benchmarks slightly dubious because everytime I look into the actual code I find that is written some obscure manner.
For example - here is the code of the Java "knucleotide" benchmark:
http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...
(If I understand the website correctly.)
Look at the way data is read (scanPastHeader, readRestIntoByteArray, fullSequence).
Or how the result of calculateHash is put into a HashMap where it immediately would be hashed again.
I think this is neither the most natural or performant way of solving the problem in Java.
Re: Java vs. Go performance
#17Look, Java is my right hand language, and I've never written a single line of Go in my life. But this is kind of unfair I think... the OpenJDK JVM has 20 years of development behind it, and has probably had mountains of money sunk into tuning f* out of it by the biggest most enterprisy players in the game. I'm sure that there is a lot of low hanging fruit for Go to grab at to improve performance, and most likely will…
I don't think it is that unfair.
From my perspective the JVM hasn't seen major performance changes since the early days e.g. Java 4. All of the major improvements have come in the library space e.g. LMAX Disruptor, OpenHFT, Javolution.
Re: Java vs. Go performance
#18Go has a significantly smaller memory usage in all of the benchmarks, often by a factor of 10x. For most workloads, this can have a huge impact on when you need to spend more money to support your business.
Re: Java vs. Go performance
#19Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Well, a lot of Java web apps ARE slow as hell, but one can't really blame Java-the-language (or the JVM) for it.
Two examples from my experience:
JSF is doing lots of "magic" trying to keep state. It isn't exactly quick to render a simple hello world page, but if you mess up the state on a somewhat complex page, JSF spends ages in it's six (yes, six!) lifecycle stages [0].
Hibernate is probably the worst offender. Well, the interface is somewhat nice: you don't have to care about loading objects from the database, Hibernate will load them for you. One object, one request at a time. Looking at the hundreds of generated SQL requests it's quite easy to figure out how you would write better SQL... but you don't write the SQL, Hibernate does :)
The lesson IMO is: If you're writing everything from scratch, language performance is important. If you're using frameworks, the performance of the whole stack is way more important and one should probably compare benchmarks - or even real-world applications that are similar to ones use case - of the whole stack.
Re: Java vs. Go performance
#20This is a pretty eye opening chart. I know the Go guys have a philosophical point about wanting to be able to reason the whole source code as the justification for the Plan 9 and later GCC only stance, but I do have to think that these numbers are poor enough that a LLVM port should be investigated. I also think that it's a good think for Go that Apple hasn't open source'd swift. I suspect it would thrash Go here.
Maybe I come from a different world, but these numbers seem pretty good. If you compare C++ and Go, C++ is 3x-1x faster than Go using more code. For most applications that you'd expect to use Go for, that's decent efficiency at a smaller memory footprint than Java. Enough, certainly, to make a high-performance server that uses less RAM than Java and less code than C++.
Go seems to be heavily optimized for write-time efficiency instead of runtime efficiency.