|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
In Java performance programming, Part 2, we looked into the basics of casting -- what it is, what it costs, and some ways you can reduce your use of it. This month, we'll cover the related issue of collections in Java, looking first at the basic collections support supplied in the original versions of Java, then moving on to the vastly improved support added in JDK 1.2. Looking ahead, we'll also examine the current state of the Java Community Process proposal for generic types in Java -- including both the benefits we're likely to see from this proposal and the areas in which it perhaps falls short.
| Java performance programming: Read the series |
|---|
We'll then take a look at ways to implement type-specific collections in Java, including an approach that uses a common base class to eliminate some of the duplicated code for these collections. Finally, we'll finish off this month's performance tips with the results of timing tests to see how our alternatives measure up.
(Note: See the sidebar below for my views on the effectiveness of Sun's Java Community Process.)
If you're developing for JDK 1.1.x, your standard collections support includes just two choices: java.util.Vector and java.util.Hashtable. (There is also java.util.Stack, but this is only a minor variation on Vector). To make matters even worse, the two choices you do have available are noticeably handicapped in the performance area. Both classes use generic java.lang.Object references, creating the need for casting -- with the overhead associated with it -- on virtually every access, and both
use synchronized methods for all accesses.
You need synchronized access methods for modifiable collections when they're used by multiple threads. However, in many cases a single thread owns and exclusively accesses a collection. In such a situation, synchronized access methods are overkill, and result in a substantial performance penalty.
We'll discuss the issue of synchronization further in the next article in this series, along with other threading issues.
If you can't wait until then, the performance comparison table near the end of this article includes figures for the legacy
Vector class that should give you a feeling for how heavy use of synchronization can affect performance.
Given the performance limitations, these old-time collection workhorses are generally best avoided in heavily used code. Just remember that they're still useful when you need only a simple collection and when performance is not a major issue.
There is a way to get improved standard collections support in JDK 1.1.x, but it comes with a price in terms of code compatibility. We'll discuss this further in the next section of this article, but for now let's limit our discussion to these two basic collections classes provided as part of the standard Java class library.