Bill and Paul's Excellent UCSD Benchmarks for Java (version 1.1)
Read this page in Romanian (courtesy of azoft)
Note: We have just updated our benchmarks to version 1.1, which
corrects a problem with synchronizing threads. The code is still 1.0
compatible. Two deprecated methods are called. See the benchmark source
There is now a host of Java compilers and interpreters, and
we need a way of telling which compilers produce better code, and which
interpreters execute them faster. To meet this need, we have produced
a small set of simple benchmarks written in Java. These were inspired by
Jon Bentley's books Programming Pearls and Writing
Using These Benchmarks
There are three ways that you can use this page to perform Java benchmarking,
run the benchmarks as an applet (if your browser supports java), download
the benchmarks yourself, or look at some results we've gathered:
Caveats and Details
- These benchmarks are simplistic and do not cover all interesting
performance issues. In particular, the loop test employs an empty
loop, and the methods and threads are trivial as well. A really good
optimizer could detect that the results of calculations are not used,
etc., and then not perform the calculation at all!
- Many of these benchmarks repeatedly perform an activity and then
report the total time. This time inevitably includes the looping
time required to repeat the activity. You can use the time returned
from the loop benchmark to factor out this effect.
- Two types of GC measurements have been performed. The first requests
that the runtime perform a full GC. Both the time and the space recovered
(and perhaps added) are reported. The second ``randomly'' allocates
several thousand objects into a small array (the time for looping and
array access are probably a small part of the overall time.), causing
most to be made available for reclamation by the garbage collector.
Because, for example, Sun's Java runtime has an incremental collector,
many of these may be collected without a full GC occuring.
- The results you get will be dependent on all aspects of your
system, including the load on the system at the time which you run the
benchmarks. This factor can complicate comparisons.
- For maximum portability, timings are peformed with
System.currentTimeMillis(). This function records wall-clock time,
so all activities of the computer are included in this time. Your
results will be most accurate if you are running on an unloaded system.
If you are running on a UNIX system, using time or uptime
will give you an idea of how much time your process is actually getting.
- We have gotten non-intuitive results in some cases, suggesting that
the Java runtime system occasionally does something (like garbage collection
or thread switching) without the benchmark specifically requesting it.
The garbage collection benchmark seems to have widely varying behavior
depending upon the environment, including crashing
(Sun's appletviewer) and thrashing/hanging (Netscape).
Authorship and Contacts
These benchmarks were authored by Bill
Griswold () and Paul Phillips.
If you have any questions or comments, please contact us!