Doug Lea wrote,
> Do you (or anyone) have any performance data comparing concatenation
> followed by String construction in nio CharBuffers vs StringBuffers?
> If this were faster, given that it already exists, it is tempting to
> just redefine String "+" to use CharBuffers, to replace nearly all
> current uses of StringBuffer with CharBuffer inside JDK library
> classes, and to encourage programmers to do likewise.
No I don't, but I doubt that there would be much to gain beyond the
explicit elimination of synch. The article that Thomas Wang posted
earlier looks useful, tho', and suggests that synch is the main
overhead. Clearly if the revised JMM makes lock elimination a viable
optimization in enough cases then these kinds of consideration have
less force.
Although this is verging off topic, I think the biggest performance
gains for my purposes would come from being able to back a String with
a readonly CharBuffer, particularly where that CharBuffer is itself a
view of a ByteBuffer with an implicit character encoding ... the
benefit here being the ability to go directly from bytes on the wire
to a String without intervening copies. The CharSequence interface
gets us quite a lot of the way there, but there's too much existing
code/APIs expressed in terms of Strings for this to help all that
much.
The point being that if JSR-133 gives us an excuse to do some work
here there are definite benefits to be had.
Cheers,
Miles
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:39 EDT