For now I have pretty much optimized the Transfer type only. no other types.
for instance I see that Disposition type needs optimization as well... For us though the biggest advantage on the patch I'm making . If you send a 1K message.. you won't have much of the optimization on the codec being exercised. we could do 10 Million Transfer in 3 seconds before... against 1.5 on my laptop. If transferring 10Million * 10K is taking 40 seconds the optimization of the 1.5 would be spread among the delivery and you wouldn't be able to see a difference. Why don't you try sending empty messages? meaning.. a message is received with an empty body. On May 1, 2014, at 4:44 PM, Rafael Schloming <r...@alum.mit.edu> wrote: > Hi Clebert, > > I've been (amongst other things) doing a little bit of investigation on > this topic over the past couple of days. I wrote a microbenchmark that > takes two engines and directly wires their transports together. It then > pumps about 10 million 1K messages from one engine to the other. I ran this > benchmark under jprofiler and codec definitely came up as a hot spot, but > when I apply your patch, I don't see any measurable difference in results. > Either way it's taking about 40 seconds to pump all the messages through. > > I'm not quite sure what is going on, but I'm guessing either the code path > you've optimized isn't coming up enough to make much of a difference, or > I've somehow messed up the measurements. I will post the benchmark shortly, > so hopefully you can check up on my measurements yourself. > > On a more mundane note, Andrew pointed out that the new files you've added > in your patch use an outdated license header. You can take a look at some > existing files in the repo to get a current license header. > > --Rafael > > > > On Wed, Apr 30, 2014 at 2:15 PM, Clebert Suconic <csuco...@redhat.com>wrote: > >> I just submitted it as a git PR: >> >> https://github.com/apache/qpid-proton/pull/1 >> >> >> >> On Apr 30, 2014, at 10:47 AM, Robbie Gemmell <robbie.gemm...@gmail.com> >> wrote: >> >>> I think anyone can sign up for ReviewBoard themselves. It certainly >> didn't >>> used to be linked to the ASF LDAP in the past, presumably for that >> reason. >>> >>> Its probably also worth noting you can initiate pull requests against the >>> github mirrors. If it hasn't already been done for the proton mirror, we >>> can have the emails that would generate be directed to this list (e.g. >>> >> http://mail-archives.apache.org/mod_mbox/qpid-dev/201401.mbox/%3c20140130180355.3cf9e916...@tyr.zones.apache.org%3E >> ). >>> We obviously can't merge the pull request via github, but you can use >>> the reviewing tools etc and the resultant patch can be downloaded or >>> attached to a JIRA and then applied in the usual fashion (I believe there >>> is a commit message syntax that can be used to trigger closing the pull >>> request). >>> >>> Robbie >>> >>> On 30 April 2014 15:22, Rafael Schloming <r...@alum.mit.edu> wrote: >>> >>>> On Wed, Apr 30, 2014 at 8:35 AM, Clebert Suconic <csuco...@redhat.com >>>>> wrote: >>>> >>>>> @Rafi: I see there is a patch review process within Apache (based on >>>> your >>>>> other thread on Java8) >>>>> >>>>> Should we make this through the patch process at some point? >>>>> >>>> >>>> I'm fine looking at it on your git branch, but if you'd like to play >> with >>>> the review tool then feel free. Just let me know if you need an account >>>> and I will try to remember how to set one up (or who to bug to get you >>>> one). ;-) >>>> >>>> --Rafael >>>> >> >>
