On Jul 14, 2008, at 08:44, Jeremias Maerki wrote:
I noticed that Andreas used CharBuffer in his initial patch for
#45390.
I was curious about the performance implications, so I wrote a little
micro-benchmark. The results:
<snip />
So this is a single-threaded test. It might perform differently in a
heavy multi-threading environment. Anyway, it looks it doesn't make
much
sense to use the CharBuffer instead of the more familiar StringBuffer
for simple string concatenation. I'm sure there's a benefit in using
CharBuffer in scenarios where nio can really show its muscles.
Yeah, it was OK for FOText, I think, but for the smaller portions,
it's probably more overkill...
I'll look into replacing what's unnecessary.
nio.CharBuffer is very suitable if there's a lot of bulk get() and put
() (like when removing leading white-space characters)
While implementing it in FOText, I noticed that if you use
CharBuffer.wrap(), you actually don't even create a new char array.
You get a CharBuffer instance that is literally wrapped around a
portion of the parameter char array).
Unfortunately, this caused issues when I started shifting characters
due to white-space-removal (as the char array was the very same one
that the parser was using to store the chars from the source XML)
I did a small test myself, before committing the changes, but that
was more focused on CharSequence.charAt() and the difference in
timing with simple index-based array fetches (for TextLayoutManager).
In that case, the difference was really negligeable, even for
millions of calls/fetches, I only got a few milliseconds difference
in total.
Cheers
Andreas
