- 78 -
•
Try to presize any collection object to be as big as it will need to be. It is better for the object to be slightly bigger than necessary than to be smaller than it needs to be. This
recommendation really applies to collections that implement size increases in such a way that objects are discarded. For example,
Vector
grows by creating a new larger internal array object, copying all the elements from and discarding the old array. Most collection
implementations have similar implementations for growing the collection beyond its current capacity, so presizing a collection to its largest potential size reduces the number of objects
discarded.
•
When multiple instances of a class need access to a particular object in a variable local to those instances, it is better to make that variable a static variable rather than have each
instance hold a separate reference. This reduces the space taken by each object one less instance variable and can also reduce the number of objects created if each instance creates
a separate object to populate that instance variable.
•
Reuse exception instances when you do not specifically require a stack trace see Section
6.1 .
This chapter presents many other standard techniques to avoid using too many objects, and identifies some known inefficiencies when using some types of objects.
4.1 Object-Creation Statistics
Objects need to be created before they can be used, and garbage-collected when they are finished with. The more objects you use, the heavier this garbage-cycling impact becomes. General object-
creation statistics are actually quite difficult to measure decisively, since you must decide exactly what to measure, what size to pregrow the heap space to, how much garbage collection impacts the
creation process if you let it kick in, etc.
For example, on a medium Pentium II, with heap space pregrown so that garbage collection does not have to kick in, you can get around half a million to a million simple objects created per second.
If the objects are very simple, even more can be garbage-collected in one second. On the other hand, if the objects are complex, with references to other objects, and include arrays like
Vector
and
StringBuffer
and nonminimal constructors, the statistics plummet to less than a quarter of a million created per second, and garbage collection can drop way down to below 100,000 objects per
second. Each object creation is roughly as expensive as a malloc in C, or a new in C++ , and there is no easy way of creating many objects together, so you cannot take advantage of efficiencies you get
using bulk allocation.
There are already runtime systems that use generational garbage collection, minimize object- creation overhead, and optimize native-code compilation. By doing this they reach up to three
million objects created and collected per second on a Pentium II, and it is likely that the average Java system should improve to get closer to that kind of performance over time. But these figures
are for basic tests, optimized to show the maximum possible object-creation throughput. In a normal application with varying size objects and constructor chains, these sorts of figures cannot be
obtained or even approached. Also bear in mind that you are doing nothing else in these tests apart from creating objects. In most applications, you are usually doing something with all those objects,
making everything much slower but significantly more useful. Avoidable object creation is definitely a significant overhead for most applications, and you can easily run through millions of
temporary objects using inefficient algorithms that create too many objects. In
Chapter 5 , we look at
an example that uses the
StreamTokenizer
class. This class creates and dereferences a huge number of objects while it parses a stream, and the effect is to slow down processing to a crawl. The
example in Chapter 5
presents a simple alternative to using a
StreamTokenizer
, which is 100 times faster: a large percentage of the speedup is gained from avoiding cycling through objects.
- 79 - Note that different VM environments produce different figures. If you plot object size against
object-creation time for various environments, most plots are monotonically increasing, i.e., it takes more time to create larger objects. But there are discrepancies here too. For example, Netscape
Version 4 running on Windows has the peculiar behavior that objects of size 4 and 12
int
s are created fastest refer to
http:www.javaworld.comjavaworldjw-09-1998jw-09-speed.html . Also,
note that JIT VMs actually have a worse problem with object creation relative to other VM activities, because JIT VMs can speed up almost every other activity, but object creation is nearly as
slow as if the JIT compiler was not there.
4.2 Object Reuse
