Hello Sangjin, I have added you to the group of Committers in JIRA, so from now on you should be able to assign JIRA issues to yourself. As you have probably seen, I have already assigned DIRMINA-610 to you.
regards, Maarten On Tue, Jul 22, 2008 at 6:45 PM, Sangjin Lee <[EMAIL PROTECTED]> wrote: > 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 >>>>> >>>>> >>>>> >>>> >>> >> >
