Other |
---|
1.3.0 kestrelFixed |
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
|
Duplicate :
|
This bug report is a combination of several reports that describe (at least) three problems with the readUTF/writeUTF methods: Problem 1: 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. peter.kessler@Eng 1998-11-19 Problem 2: 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. rws@east Problem 3: 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. pbk@eng -- mr@eng 1999/4/19
|