Java Reference
In-Depth Information
Table 10-12. Time to serialize and deserialize 10,000 objects with compression
Use case
Serialization time Deserialization time Size of data
No compression
12.1 seconds
8.0 seconds
41,170 bytes
Compression/decompression 26.8 seconds
12.7 seconds
5,849 bytes
Compression only
26.8 seconds
0.494 seconds
5,849 bytes
The most interesting point about this table is the last line. In that test, the data is compressed
before sending, but the unzipPrices() method isn't called in the readObject() method.
Instead, it is called when needed, which will be the first time the client calls the getPrice()
method. Absent that call, there are only a few BigDecimal objects to deserialize, which is
quite fast.
It is quite possible in this example that the client will never need the actual prices: the client
may only need to call the getHighPrice() and similar methods to retrieve aggregate in-
formation about the data. As long as those methods are all that is needed, a lot of time can be
saved by lazily decompressing the prices information. This lazy decompression is also
quite useful if the object in question is being persisted (e.g., if it is HTTP session state that is
being stored as a backup copy in case the application server fails). Lazily decompressing the
data saves both CPU time (from skipping the decompression) and memory (since the com-
pressed data takes up less space).
So even if the application runs on a local, high-speed network—and particularly if the goal is
to save memory rather than time—compressing data for serialization and then lazily decom-
pressing it can be quite useful.
If the point of the serialization is to transfer data over the network, then the compression will
win any time there is data savings. Table 10-13 performs the same serialization for the
10,000 stock objects, but this time it transmits the data to another process. The other process
is either on the same machine, or on a machine accessed via my broadband connection.
Search WWH ::

Custom Search