Page 134
Key Points . Output buffering is one of the two big issues with stream output performance. Buffering spreads the fixed cost of an I/O call over a large number of bytes and reduces the cost per byte. There’s no need to write any buffering code yourself. The I/O library is already equipped with buffered streams. Just use them. . Buffering efficiency is sensitive to the size of the underlying buffer. The default sizes seem to be okay. If you choose to conserve memory and lower the size of the buffer, remember that as the size of the buffer decreases, performance gains slowly evaporate. . Frequent, periodic flushes may undermine the buffering mechanism. Pick your flushing spots carefully. . If you turn on the autoFlush feature of the PrintWriter, you can forget about efficiency. . Conversion of Unicode characters to bytes is expensive. Consequently, it is faster to send a byte array down a stream than a Unicode String through a writer. . Failure to buffer input data will result in physical reads of a single byte at a time. It could degrade performance by an order of magnitude. This loss is worse than a failure to buffer output because your typical output calls will attempt to write more than a single byte. . The DataInputStream will outperform input readers when ASCII streams are being read. The DataInputStream performs a proper byte-to-Unicode conversion for ASCII streams only. This is the classic tradeoff between speed and flexibility. . Not surprisingly, reading and writing binary data is vastly superior (in performance) to reading and writing Unicode characters. Page 135
Hint: This post is supported by Gama hrvatski web hosting services