Second Article Review
Sosnoski , D. (November 1999)
Java Performance Programming, Part 1: Smart Object
Management Saves the Day
Java World p.1
This article included a link to Java Memory Management Performance Benchmark Files, which
were used to conduct the experiments. They can be found here:
is a review of the article “Java Performance Programming, Part 1:
Management Saves the Day
written by Dennis Sosnoski.
This article was
because of the performance improvements offered to programmers by giving the
e opportunity to understand how to reduce the volume of object creation
in their code.
A code with less volume will usually compile faster and allow the
programmer to make the most efficient work of the Java Virtual Machine.
of this review
will be to illustrate what the components of Java Performance are,
according to the article
s to the C/C++ programming languages
Then it will take a more in
depth look at Object Management in Java, and some of the
techniques used to
reduce the volume of object creation and garbage collection in Java
stated in the article.
The main purpose of this article
s to explain to programmers that
areas in which Java performance is not up to par, there are te
described in this article
that will circumvent
These improvements can be achieved by writing additional code or by changing the way
code implements an idea.
The article has a graph of just how much memory
for simple objects on various Java Virtual Machines to show the memory overhead that a
Java Virtual Machine can add. The JRE by IBM takes up 63 bytes per object. A large
number of small objects shuffling numbers back and forth can cripple a
It was important for Sosnoski to write this article because there is a race for
vendors to provide the best programming language
to the programming world
who writes an article on techniques and theories th
at help to improve the performance of
programming language helps to make that language more acceptable as a
standard. Although Java can be run as platform independent software, this is not a
convincing argument for programmers to want to swit
ch to the Java Language. Speed
and efficient hardware use are big factors in getting a language accepted into today’s
programming world. This article sets out to improve the speed and efficiency of Java
code, and along with it, the acceptance of Java as
a programming language.
The new idea that the article uncovered was that there are certain elements of
Object use that will significantly slow down speed performance when trying to make an
effective comparison between the Java language, and its direct
competing languages. For
most operations, Java was within a few percent of C/C++ in relation to time and
efficiency. Some computational performances were showing that IBM’s Java Virtual
Machine had the potential to start moving past C/C++’s performances.
A time when this
Second Article Review
will not happen, though, is when a great deal of objects are being created and discarded,
because initialization time for adding overhead information, garbage collection time, and
structural differences between the languages will slow dow
n performance. Key methods
for avoiding problems included using primitive types in place of objects,
(either through Dedicated Object Reuse or via the Free Pool Approach), and using owned
The author has a 25
year background in d
eveloping for a wide range of platforms
and application areas.
seems to draw on this experience, as well as several
benchmarking applications, to get the facts for his article. The three benchmarking
applications that were used are linked to the
article and can be downloaded for users to
try out on their own machines. They include a Memory Benchmark written in Java, a
Memory Allocation Benchmark written in C++, and
a zipped C++ Executable file. The
parameters to recreate his experiments are als
o listed on the linked up site. For memory
usage of Objects, a program that does not take any command line parameters was used.
The values used by the program were hard
coded into the program as static constants.
One of the strengths of the paper was t
hat author Sosnoski included the code to
illustrate what he meant by the proper ways in which to write code that would reduce
of these performance issues.
If the reader has a background in Java programming,
this reviewer did,
inserting code exampl
he reader to
get a better view of
what Sosnoski was referring to
of owned objects vs.
dedicated object reuse.
these made it clear to the reader that the lazy programmer is not always the
Especially in ca
ses where one was recalling the date and had the
option of programming 8 more lines for a faster, by 42 seconds, run time, each time.
use of visual graphs and charts also helped Sosnoski get his point across to the reader.
Any visual representation o
f such an abstract concept
as the majority of the material
was greatly appreciated.
While the second half of the article’s points are demonstrated by examples of code,
he first half of the article
has laid out chart tables as its v
isual aids. The
examples of test
results shown via 2
charts explain the differences between the many JRE’s
on the market.
This was very helpful as it showed that programmers might not be aware
of how memory usage might be affected by using di
Although Sosnoski makes a valid point for switching over to the methods he
describes as being better for overall compilation
, he also seems to set the tone that he is
for adopting the C/C++ language in the beginning of the article. Sosn
oski begins by
saying that Java is now close, but not quite comparable, to C/C++ in terms of
. Even his charts show that C++ is faster by about 15 seconds in terms of
term memory allocation.
This is confusing because it suggests to
starting to read the article that the general feeling is that even at the end of the paper, we
are going to learn
that Java can not catch up to the C/C++ language. There is no reason
to finish reading a paper on the performance enhancements
of a language A, while the
author is making the audience feel that language A will never be as good as language B.
In fact, it isn’t until the paragraph before the author’s own conclusion that he comes back
Second Article Review
to the C/C++ vs. Java argument. Here he suggest
there are moments when C++ is
not as good as Java, but still he fails to instill the confidence in the language that he
pulled out from underneath his readers in the beginning of the article. This trick did not
enhance the article to the benefit of
In conclusion, this article for the most part gives good details on how to cut out many
of the problems associated with compilation lag. If programmers reduce the volume of
the code that is created at compile time by objects in their progra
ms, the computer has
less data it has to sift through to execute the pro
gram successfully. The article, through
the use of Object management, makes a claim of better performance that will only be
seen if programmers take the extra steps to add the newer t
echniques to their
programming style. The next step is to see how the programmers will adapt to the
change in Java programming.