This bug report is a combination of several reports that describe (at least)
three problems with the readUTF/writeUTF methods:
DataOutputStream.writeUTF runs through its argument String twice using
String.charAt. Instead, it could use String.getChars to get the chars into
a local char and then walk that (twice). This would save two calls to
String.charAt per char, and would avoid the explicit range checks that
String.charAt does. One hopes this change would allow a good compiler to
elide the subscript range checks on the array access, etc. generating
generally better code.
One might want to avoid the extra char if the argument String were very
long, to avoid running out of memory.
DataInputStream.readUTF is using a public String constructor, which forces
the char array to always be reallocated and copied. It is frequently the
case that the char array created by readUTF will be of exactly the right
length, and could be used as-is, without copying, if only there was a
privilged way for it to create a String.
In an RMI server that I have, which involves serialization via RMI and then
serialization to a file for persistent storage, over 4Kb of heap is
allocated and then discarded by readUTF per single RMI call to the server.
It would be very beneficial to eliminate this overhead.
DataOutputStream.writeUTF computes single bytes of the resulting UTF and
writes them to the stream one byte at a time. That's okay for buffered
output streams, but for ByteArrayOutputStreams (or unbuffered streams) that
results in a synchronized method call per byte (at least).
Similarly for DataInputStream.readUTF reading from a ByteArrayInputStream.
-- mr@eng 1999/4/19