Hi Paulo,
Hi Pavel.
On Thu, Jun 21, 2012 at 2:13 PM, Pavel Porvatov
<pavel.porva...@oracle.com <mailto:pavel.porva...@oracle.com>> wrote:
Hi Paulo,
Hi. I've noticed that DefaultStyledDocument has a slowness
issue when inserting text. Even if you subclass it and expose
the faster method:
protected void insert(int offset, ElementSpec[] data)
the body of the method still uses a stringbuilder to append
all char[] inside of the data before actually inserting into
the content.
This is because the only method for insertion in the default
content interface is:
public UndoableEdit insertString(int where, String str)
Now if there are going to be extension methods in java 8, it
would be nice to have a
public UndoableEdit insert(int where, int index, int length,
char[] str) default {
return insert(where, new String(index, length, str);
}
In which class do you suggest to add the new method?
It would need to be part of AbstractDocument.Content with the new
extension method feature in order to be able to be part of the public
interface of Content and be useable generally without casts.
Unfortunately we can't do that because of backward compatibility.
I suppose you can also just modify the current method
DefaultStyledDocument.insert(int offset, ElementSpec[] data)
by using 'getContent() instanceof GapContent', casting and using the
GapVector (superclass of GapContent) replace method directly, instead
of going through the public Content API, which needs to a string (thus
the stringbuilder, creating a string that is only used as a char []
holder.
with a adequate specialization in GapContent (that obviously
doesn't call the string version), and that that new method is
used in the
protected void insert(int offset, ElementSpec[] data)
method (and where it makes sense)
I'm not sure I understand correctly the last sentence. Could you
please clarify that, please?
It's how i understood the new extension methods work; you provide a
simple no-state implementation in the interface (which is possible in
this case with AbstractDocument.Content.insertString(int where, String
str) ) and then implementations specialize the method for speed.
I was also speculating that this is maybe not the only place where
such a method makes sense.
Anyway, the speed penalty of the buffered insert (which you have to
extend DefaultStyledDocument or use reflection to access anyway) of
first creating a new large string with all the text that is only going
to be String.toCharArray() in the next method is very significant if
your text is actually something you'd like to buffer (like war and
peace for instance).
Either way that the bulk insert method is improved, either by
instanceof cast or new public api in Content taking advantage of
extension methods, i think it should be fixed.
If you have ideas how to fix some problems or improve some functionality
in jdk you can become a contributor, see details here
http://openjdk.java.net/contribute/
Regards, Pavel
