Thanks! On Tue, Jul 22, 2008 at 12:21 PM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
> 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 > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > >
