On Java being slow (was Re: C++, C# or Java.)

Thomas G. Marshall wrote:
> Very common mantra from nearly every java pundit except me. I very much
> like java, and will likely be a proponent of it for a very long time, but in
> real life, it is "slow" when compared to anything else native.

I agree with you. Now, I don't consider myself a Java "pundit", so I
don't know if that disproves your statement or not. I do use Java a
lot. Nevertheless, it makes sense from the standpoint of objective
decision-making to admit that Java is mostly slower than native code.

I don't think I'd go so far as you, though. I don't agree that:

> the consensus is still that the JVM just cannot
> come close to a "real" cpu.

Java certainly can come close to a real CPU. I find it to be comparable
in micro-benchmarking, and within 20% in real-world application testing,
of the performance of applications compiled straight to machine code.
Of course, these are generalizations, but they describe my experience,
and I think it meets the definition of "close" fairly well.

There seem to be four factors that account for the "slow" reputation, in
no particular order:

1. Poor programmers
2. Garbage collection
3. Memory/locality issues
4. Pure object model

Poor programmers is a somewhat standard excuse, but one that holds some
merit. Java is definitely more accessible to the novice programmer than
C and C++ were; and as a result, there are plenty of examples of poor
code in Java. In general, though, evidence of poor code takes the form
of bad design and abstraction, as even poor programmers can write
reasonably well-performing code in 90% of situations. In fact, many
poor programmers are obsessed with it!

Garbage collection, of course, can theoretically be made faster than
explicit memory management when given enough memory, as Andrew Appel is
famous for having argued. I believe it's important to realize that GC
opens up new ways of managing a heap that have their own unique
advantages performance-wise over an explicitly managed heap.
Nevertheless, in practice, garbage collection is generally slower except
in certain specialized algorithms that can exploit it efficiently.
Java's being fundamentally based on garbage collection has many benefits
for safety, ease-of-development, and security... but it objectively must
be admitted to be slower on average.

The most overlooked reason for Java's performance problems is the
difficulty of maintaining good cache and page locality. Because Java's
microbenchmark improvements have come at the cost of memory usage, Java
processes are often larger than native processes. They maintain two
copies of a lot of the code (native and bytecode), and they lack the use
of shared libraries so that memory becomes even more scarce when
multiple virtual machines are running. They also maintain a lot more
information at runtime than a typical C or C++ application, for the
purpose of providing powerful features like OO dynamic linking/loading
and reflection. The result is a higher likelihood of paging and of
cache misses, both of which slow things down. This is largely a direct
cost of the bytecode format. It also accounts for much of the curious
fact that simple benchmarks often show Java at comparable performance
with native code, but real-world (larger) applications fail to
demonstrate such similar performance.

The pure object model (by which I mean that all objects own their
identity and therefore do not have a lifetime tied to local scope) is
perhaps a bigger concern. It exacerbates both the garbage collection
impact (because garbage collection runs more often) and the locality
impact (because data is not stored as compactly or contiguously in
memory) as described above.

> Now saying this often causes very emotional kneejerk reactions.
>

Yes, it does. Loyalty is a natural human emotion, whether it's
appropriate or not.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
.

Relevant Pages

  • Re: forth and virtual memory
    ... too, maybe even the same order, so ordering the blocks by allocation ... on systems with too little memory ... What Java is known for, and what it actually does, are two distinct ... My measurements indicate that some of the benchmarks (from SpecJVM98, ...
    (comp.lang.forth)
  • Re: Heap and Memory Footprint
    ... If you have any mixed language objects (i.e. Java objects which have underlying native memory associated), when the object is created memory is allocated in both the Java heap and the C native heap. ... It is important to explicitly call close- otherwise if the object gets promoted to the old area, the memory will not be freed until the object gets garbage collected from the old area which can take a very, very long time (and in the worst case you may have the process hit a memory limit without a garbage collection occurring as only the Java heap's behaviour will trigger garbage collection). ...
    (comp.lang.java.machine)
  • Re: What is the fastest method of parsing scheme?
    ... These issues can be eliminated by the use of custom memory allocators ... Any other ideas why Scheme would be faster than C++ and Java for heap ... For example, in my compiler, the procedure ) ...
    (comp.lang.scheme)
  • Re: JVM/Java memory footprint
    ... I found that if I use Java for developing the CLI ... application I will be exhausting the memory of our Application Server ... Just to mention the architecture,users use ... what WHAT specific REASON do you have to make ...
    (comp.lang.java.programmer)
  • Re: Function pointers (Callback functions) in Java ?
    ... > allocate a memory pool from which I can request memory slices as and ... Java however, does not support structures like C does. ... This is a data centric solution, ... So for a callback, you cannot use anything other than ...
    (comp.lang.java.programmer)