I see two differences between the trunk and the 1.1 branch that are relevant to this. (1) direct buffer vs. heap buffer It seems that a direct buffer performs much more poorly in this regard than a heap buffer. The trunk creates a heap buffer by default but the 1.1 branch creates a direct buffer by default. It is perhaps related to this issue: https://issues.apache.org/jira/browse/DIRMINA-289.
The question is, if the heap buffer default is good enough for the trunk, then shouldn't it be good for the 1.1 branch as well? (2) There is one more piece of optimization that's done in the trunk version. Namely, if the backing buffer has an associated byte array, then the algorithm of identifying the first zero byte is done by iterating over the array instead of repeated hasRemaining() and get() calls. This optimization applies only to heap buffers. I think these changes are worth backporting to the 1.1 branch (and perhaps the 1.0 branch?). Thoughts? If you agree, I'll open a JIRA issue to track this. Sangjin On Thu, Jul 17, 2008 at 3:51 PM, Sangjin Lee <[EMAIL PROTECTED]> wrote: > 2.0 performs pretty close to the NIO level. > Here's a quick test you can compare the performance with... > > Sangjin > > > On Thu, Jul 17, 2008 at 2:19 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> > wrote: > >> Hi guys, >> >> this is interesting. >> >> If you have some code with those performance tests, that could also help. >> >> Otherwise, did you made some tests on 2.0 ? >> >> >> Julien Vermillard wrote: >> >>> On Thu, 17 Jul 2008 09:52:38 -0700 >>> "Sangjin Lee" <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>>> Forgot to add that this is a pretty crucial method. Any text based >>>> decoder would need to use it to decode messages... Thanks! >>>> Sangjin >>>> >>>> On Thu, Jul 17, 2008 at 9:51 AM, Sangjin Lee <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>> I've been looking at some performance characteristics of >>>>> ByteBuffer.getString() in 1.1.x, and noticed that it is >>>>> considerably slower than its NIO counterpart. I tested it with a >>>>> few JVMs, and ByteBuffer.getString() performs anywhere between 3 - >>>>> 5 times poorer than the NIO version. NIO does not have the >>>>> getString() method, and one would use CharsetDecoder.decode(). >>>>> I also checked the trunk version (IoBuffer.getString()), and it >>>>> seems much faster and pretty close to the NIO performance. >>>>> >>>>> How is a performance issue with 1.1.x like this normally handled? >>>>> Are we open to investigate and fix performance problems like this >>>>> in 1.1.x as long as it does not entail API changes? If a simple >>>>> change for IoBuffer resulted in this performance enhancement, >>>>> perhaps we can backport that change? >>>>> >>>>> Thanks, >>>>> Sangjin >>>>> >>>>> >>>>> >>>>> >>>> >>> Hi Sangjin, >>> >>> I don't see any problem in patching 1.X for perfs. It's some kind of >>> bugfix ;) >>> >>> Julien >>> >>> >> >> >> -- >> -- >> cordialement, regards, >> Emmanuel Lécharny >> www.iktek.com >> directory.apache.org >> >> >> >
