Adding a fixate method to StringBuilder and StringBuffer.
Paulo Levi
i30817 at gmail.com
Thu Apr 16 17:44:47 UTC 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
BadLocationException {
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...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20090416/6d78681c/attachment.html>
More information about the core-libs-dev
mailing list