This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Posted by Dave Trissel on 28 May 1998, 10:53 AM
The optimization lore list addresses the major speed weaknesses
of current JVMs. However, if your JVM supports a JIT then the
second point about making classes large to avoid method call
overhead can actually slow things down. Larger methods mean
more simultaneously active local variables and this can create
a situation where not as many locals are assigned to native
hardware registers. Depending upon the program the extra loading
and storing of unassigned locals can generate more overhead
than that the method calls for an alternative method partitioned
For non-JIT interpreted situations the Java bytecode
instruction set favors the accessing of the first four local
variables in a frame since these have implicit reference forms.
As a result, the same code sequence may execute faster in a
smaller method than in a larger one. However, method call overhead
is so large that it is generally not beneficial to partition
code into smaller methods.