JDK-4147390 : java.io.DataInputStream.readUTF should avoid copying char[] data
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 1998-06-10
  • Updated: 1999-04-19
  • Resolved: 1999-04-19
Related Reports
Duplicate :  
JDK-4219771 - java.io.Data{Input,Output}Stream: Improve performance of {read,write}UTF
Description
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.
Comments
WORK AROUND None.
11-06-2004
PUBLIC COMMENTS 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.
10-06-2004
SUGGESTED FIX One option is to use a native method to create the String. Another option might be to keep a char[] buffer around as a field of DataInputStream and reuse it (allocating a new one if the UTF length is larger than the current buffer, possibly throwing it away if it becomes too large, or possibly holding a soft reference to it). [Bob Scheifler 1998-06-10] There is a String constructor that takes a StringBuffer that would achieve the desired effect of not reallocating the char array a second time. public final static String readUTF(DataInput in) throws IOException { int utflen = in.readUnsignedShort(); Change char str[] = new char[utflen]; To StringBuffer str = new StringBuffer(utflen); All accessed to str[] need to be changed to StringBuffer.setCharAt() Since StringBuffer is final, there exists a chance that setCharAt can be inlined to avoid the overhead of many fct calls. And the final return would be new String(str); This constructor converts a StringBuffer into a String efficiently as long as no ever modifes str, which they will not be able to. [joseph.fialli@East 1998-06-10] But StringBuffer is synchronized, an undesirable performance penalty. [bob.scheifler@East 1998-06-10]
10-06-1998