It would not be
too unfair to any language to refer to Java as a stripped down Lisp
or Smalltalk with a C syntax.
Thus, a Java programmer must be concerned with many of the same
performance issues that a Lisp programmer would.
Study the Virtual Machine
Java is based on a Virtual Machine architecture, JVM, based on
a byte-code interpreter.
Performance of Java systems can vary considerably based on how the
VM is implemented. For example the performance of the JVM for JDK 1.1.2
was double that of JDK 1.0.2. "Just in time" compilers (JIT) for Java
can be considerably faster than a byte-code interpreted version.
Even if you plan to use a JIT, it is important to understand the JVM, to
get an understanding of relative costs of operations.
Avoid redundant field or array accesses in loops
In rough order of increasing cost:
- local variable (including method arguments)
- field
- array
In loops, move field and array references into local-variables. Don't trust
a compile to deduce that a field will not change in a loop. This quite
hard to deduce in a multithreaded environment.
Declare methods "final" later
Declaring a method or class "final" allows certain optimizations.
For example, method dispatch can be eliminated, and methods can be inlined.
See Inline later.
Garbadge collection
Garbage collection is a good thing.
See Garbage collection hint.
Benchmarks
Mike Thome had redone the Fannkuch and polygon benchmarks
for C, Java 1.1.3 VM and JIT. See Papers
for details.
X-Authentication-Warning: stout.bbn.com: majdart set sender to owner-java@stout.bbn.com using -f
X-Sender: mthome@zima.bbn.com
Date: Tue, 15 Jul 1997 11:56:08 -0400
To: java@bbn.com
From: Michael Thome
Subject: JDK performance
Mime-Version: 1.0
Sender: owner-java@bbn.com
Precedence: bulk
I thought I'd share some interesting results re Java performance...
I wanted to get some idea of how much the JDK 1.1.3 windows performance
package JIT really helped... the answer led me to compare with C
performance on the same machine. The benchmark is a simple integer
benchmark known as Fannkuch - nothing fancy here, just a benchmark which
we've used to measure gross relative performance between machines. I
ported the C version to java and ran both versions using different
compiler/vm/etc combinations, all executing on a Pentium Pro 200 running
windows NT.
language compiler/VM options time(ms) normalized to best
C MS VC 5.0 release 4737 1.0
debug 13340 2.82
gcc 2.7.2 -O4 7450 1.57
(default) 13479 2.85
java JDK 1.1.3 (default) 191866 40.5
JIT 9293 1.96 !!
Java within a factor of 2 of C's best time!?! Maybe Sun isn't just blowing
smoke after all...
-mik
X-Authentication-Warning: stout.bbn.com: majdart set sender to owner-java@stout.bbn.com using -f
X-Sender: mthome@zima.bbn.com
Date: Tue, 15 Jul 1997 12:24:20 -0400
To: Michael Thome
From: Michael Thome
Subject: Re: JDK performance
Cc: java@bbn.com
Mime-Version: 1.0
Sender: owner-java@bbn.com
Precedence: bulk
At 11:56 AM 7/15/97 -0400, Michael Thome wrote:
>I thought I'd share some interesting results re Java performance...
A short followup:
Ken Anderson supplied me with another multi-language benchmark which uses
floating-point arithmetic to compute the "is the point inside the polygon"
test. Here are the results (those with John Watton's paper can compare to
the paper's results based on the performance of the first case). Again:
same machine.
language compiler options time normalized to gcc-O3
C gcc 2.7.2 -O3 4716 1.0
(default) 9643 2.04
java JDK 1.1.3 -O, nojit 50663 10.7
-O, jit 4467 .947 !!
Cool - Java beats optimized gcc!
-mik
Ken Anderson