Adding a fixate method to StringBuilder and StringBuffer.
i30817 at gmail.com
Thu Apr 16 10:44:47 PDT 2009
---------- Forwarded message ----------
From: Paulo Levi <i30817 at gmail.com>
Date: Thu, Apr 16, 2009 at 6:43 PM
Subject: Re: Adding a fixate method to StringBuilder and StringBuffer.
To: Jesús Viñuales <serverperformance at gmail.com>
How about the charsequence2 interface for readonly views? It would not
resolve the problem of a third party modifying the chars from under the
methods, but frankly that problem exists today now, since the only
performant methods of insertion are all based on char and not Strings
(that i will remind you, need at least 2 char array allocations to be used
in a api (making the array, copying the chars, (sometimes - making the
string buffer, copying the arrays,), toCharArray(), copying the chars,
Vs 1 allocation in a more sane api, making the string array and copying the
char array at source and destination.
The char methods methods are also badly implemented in that they just use
new StringBuffer (not even builder) and toString(), effectively doubling or
tripling the memory requirements - for buffered insertions, that logically
take a large amount of chars.
For instance, I call you attention to the method:
protected void insert(int offset, ElementSpec data) throws
in defaultStyledDocument, that aquires an internal writelock, uses a
StringBuffer to append each array into a gigantic string and calls
insertString(offset, string); on the GapContent, that then uses toCharArray
instead getChars to make another unnecessary allocation. Is it any wonder
that methods throw OOM?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the core-libs-dev