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

Java vs. Go performance

benchmarksgame.alioth.debian.org

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Java vs. Go performance

#21

Post by vetler »

CookWithMe wrote: post #19
hanief wrote: post #11

Interesting. 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. We…

Well, to be fair, Hibernate is just a tool - and as many tools, it can be used the wrong way and the right way. Most people seem to not spend any time to learn how to use it, and then complain when it doesn't magically read their mind. It's leaky, like all abstractions. You have to understand how it works, and how databases works. There's always the option to write HQL or JPQL as well, or even fall back to SQL if all else fails.

It's not Hibernate's fault that you eager load everything, always load entire entities when you just need a single boolean field, or loop over entity collections to aggregate values - Hibernate is just a tool, and it's the developers who are telling it what to do.

Re: Java vs. Go performance

#22

Post by craftit »

As I understand it, Go also give some guarantees about the maximum amount of time the garbage collection will stall the program. An issue where ever you are trying to achieve consistent performance. As I understand it most of the java benchmarks postpone clearing up memory until it can be done trivially at exit, something you just can't do in a whole class of programs.

Re: Java vs. Go performance

#23

Post by hugi »

threeseed wrote: post #12
hanief wrote: post #11

Interesting. 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.

Probably part of it, but for me, the somewhat uncanny valley-ish non-standard look and behaviour of Swing UIs (and AWT before that) is the biggest turn off. Using java apps on the desktop feels a little like using a keyboard with mittens.

Re: Java vs. Go performance

#24

Post by logicchains »

Since we're posting benchmarks, here's Java vs Haskell: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan.... The Haskell implementations generally use much less memory than the Java ones and perform competitively. In spite of criticism that some of the Haskell implementations are not idiomatic, they're no more verbose than the Java ones in terms of LOC.

Re: Java vs. Go performance

#25

Post by Skinney »

craftit wrote: post #22

As I understand it, Go also give some guarantees about the maximum amount of time the garbage collection will stall the program. An issue where ever you are trying to achieve consistent performance. As I understand it most of the java benchmarks postpone clearing up memory until it can be done trivially at exit, something you just can't do in a whole class of programs.

Not yet, but that is planned for the next release.

Re: Java vs. Go performance

#26

Post by Skinney »

unoti wrote: post #18

Go 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.

It also has a large impact on how often the GC is run. Less memory used, less GC performed.

Re: Java vs. Go performance

#27

Post by saiya-jin »

vetler wrote: post #21
CookWithMe wrote: post #19

Earlier quoted context omitted.

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

Well, to be fair, Hibernate is just a tool - and as many tools, it can be used the wrong way and the right way. Most people seem to not spend any time to learn how to use it, and then complain when it doesn't magically read their mind. It's leaky, like all abstractions. You have to understand how it works, and how databases works. There's always the option to write HQL or JPQL as well, or even fall back to SQL if all…

true, but... if so many developers end up having issues on not-trivial-hello-world-employee-customer example, then maybe, but just maybe it's not the best tool for most. I mean, it's around for ages, the principle didn't change a bit, and same issues again and again.

One thing that I don't like about Hibernate - most projects evolve, for a very long time even after delivery. Messing with OR mappings (which most changes do) can include a lot of regression on performance side, much more than SQL (unless you do something horrible on DB level). Also, the more complex data model is (and often you don't choose how it's done), the less benefits you get from solutions like these.

Re: Java vs. Go performance

#28

Post by saiya-jin »

hugi wrote: post #23
threeseed wrote: post #12

Earlier quoted context omitted.

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.

Probably part of it, but for me, the somewhat uncanny valley-ish non-standard look and behaviour of Swing UIs (and AWT before that) is the biggest turn off. Using java apps on the desktop feels a little like using a keyboard with mittens.

This is an issue of unskilled devs using ancient UI design approach, usually not even bothering with skinning it.

Things like bitTorrent were done in Java (correct me if I'm wrong), and you have no clue which language they are done in when looking at UI. But this a bit of extra effort, and for intranet apps, nobody usually bothers.

Another reason for oh-not-so-windows-look of UI is something microsoft finally begun discovering - that there are other platforms than Windows. Java UI works anywhere where you have working JRE, and if you've ever seen Linux's KDE/GNOME/XFCE etc. then you might realize it ain't easy to come up with a cross-section between them.

You need to hack things with Wine or similar to have it +-++ work the other way around (ie MFC app -> anywhere but MS world, and even there it might be tricky with all dll hell).

Re: Java vs. Go performance

#29

Post by nextw33k »

This benchmark is out of date almost immediately because of the patch level of the Java runtime and the Golang compilers change frequently.

I was half thinking of creating a VB6 module for LLVM just as a tongue in cheek joke of taking a language with a slow runtime and effectively strapping a V8 engine to it, but I saw someone already did most of the work: https://github.com/microcai/llvm-qbasic

Re: Java vs. Go performance

#30

Post by xtrumanx »

CookWithMe wrote: post #19
hanief wrote: post #11

Interesting. 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. We…

What's wrong with having six lifecycle stages? I don't use JSF (or Java) but I can understand the usefulness of having several lifecycle methods assuming you can hook into them and add your own custom logic. The more lifecycle stages the more precisely you can choose when during the request processing your custom logic should be invoked.
Post reply on HN