41–50 of 69 posts
Interesting. All this time I have a perception that Java app is slow as hell. What a terribly wrong assumption. Color me impressed.
Earlier quoted context omitted.
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.
You can't fine-tune memory usage and can run into cache issues (or worse) if you deal with quite a lot of data, though.
What do you mean by that? There are some very fine-grained tuning options if you really need them.
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.
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.
Earlier quoted context omitted.
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.
What perspective is that? They ship new optimisations in more or less every release. I'm not sure what workload you do that you've never seen performance improvements. For example in Java 9 they're going to ship auto-vectorisation for certain kinds of functional / parallel stream construct.
I am not saying there weren't any benefits from the JVM over the years only that the biggest gains I've experienced have come from new types of libraries.
Fully agree with Java 9 though. It is the first release that I've been really excited about. Project Jigsaw has the potential to fundamentally reimagine the entire platform.
Earlier quoted context omitted.
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.
You can't fine-tune memory usage and can run into cache issues (or worse) if you deal with quite a lot of data, though.
http://www.oracle.com/technetwork/articles/java/vmoptions-js...
And don't forget that much of big data is on the JVM e.g. Hadoop, Cassandra, HBase.
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…
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.
The root cause is really that (a) they're forcing a stateful model onto the web and (b) that the way they're keeping/restoring the state is expensive.
The lifecycle stages are more a sympton of that. Most web framework these days go with a stateless approach. One notable exception is the lift framework for scala (although I'm not sure if it's really active anymore). I have only looked very briefly at it, but it seemed to give the programmer more explicit control of the state...
A simplified example to demonstrate the problem: Imagine a B2B app with a medium-sized table, where each row contains multiple objects. A HTTP request is send for performing an action on one object.
In a stateless approach, the programmer decides which objects he needs to serve the request. In JSF, the framework restores the complete state as seen in the previous request, and will also setup a lot of other magic (event handlers, validators, what not) - no matter whether it is actually needed to serve the request or not.
So one ends up with stages in the lifecycle that waste a lot of time, but one really hasn't much control over.
Look, 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.
Look, 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…
My understanding is that Go has a very simple optimizer. They were waiting for all the C code in the compiler to be translated to Go, which I believe was done in the last release.
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.