As mentioned in the preceding section, Color objects are stored in a hash table rather than creating the same ones over and over. As a further optimization, we created our own version of Java’s Hashtable class, which uses normal ints as keys rather than requiring an Object handle Integer data needs much less room to store in the pixel array Ulan Color objects, so we-use-a hash table as a mechanism to look up Color objects fromtheInteger value of any individual pixel. Creating Color objects on the fly from the integer value of each pixel is very expensive, because it creates a lot of memory garbage that must be collected, one possible solution would be to use a Java Hashtable, except that doing so would create just as much garbage, since only objects can be used as keys in a standard . Java hash table. Thus, to store an int in Java’s hash table,would have to create a new Integer object as a key to be matched. In a high duty. cycle applet like Lavatron, garbage .Integer objects would be created by the thousands per second. nus is not a good solution.
The proper solution was to build our own hash table, IntHash, which uses the integer d~ta type values rather than ~ Integer object for its keys. IntHash is about 60 lines of code. The IntHash class duplicates the interface of the java.util.Hasbtable class with the exception that the type of the argument to put( ) and g~t( ) is an int data type rather than an Object.