I have updated the JIRA issue for this with a suggested patch: https://issues.apache.org/jira/browse/DIRMINA-610. If someone could take a quick look and review the changes I would greatly appreciate it. The changes are essentially backporting a couple of fixes that were made on the trunk with little modifications: - useDirectBuffers defaults to false - introduced the indexOf() method and the related optimization in finding the zero byte
The only change I made from the original fix is that on the trunk the indexOf() method is part of the interface, but it is not on the 1.x branches. So I made it a private method not to cause any changes in the API. Also, there is a call to hasArray() in the indexOf() method implementation, but since the 1.x branches do not have this method, I used the equivalent, which is buf().hasArray(). I'd love to commit the changes myself, but somehow I cannot assign the bug to myself. If someone could take a look at the JIRA permissions and/or assign it to me, I could go ahead and commit it. If someone would be nice enough to commit it for me, that would be fine too... Thanks! Regards, Sangjin On Thu, Jul 17, 2008 at 4:27 PM, Sangjin Lee <[EMAIL PROTECTED]> wrote: > The second change was this: > http://svn.apache.org/viewvc?view=rev&revision=477482. > Regards, > Sangjin > > > On Thu, Jul 17, 2008 at 4:11 PM, Sangjin Lee <[EMAIL PROTECTED]> wrote: > >> 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 >>>> >>>> >>>> >>> >> >
