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.



Reply via email to