qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Stitcher" <astitc...@apache.org>
Subject Re: Review Request 25590: six percent speedup from inlining one function.
Date Fri, 12 Sep 2014 20:17:41 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25590/#review53212
-----------------------------------------------------------

Ship it!


Looks fine to me. I'd be wary if this was exposed via the visible API as it would have ABI
implications, but as it is purely internal I think its fine.

- Andrew Stitcher


On Sept. 12, 2014, 7:46 p.m., mick goulish wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25590/
> -----------------------------------------------------------
> 
> (Updated Sept. 12, 2014, 7:46 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Andrew Stitcher, Gordon Sim, and Rafael Schloming.
> 
> 
> Repository: qpid
> 
> 
> Description
> -------
> 
> proton:  six percent speedup from inlining pn_data_node()
> 
> 
> Diffs
> -----
> 
>   proton/trunk/proton-c/src/codec/codec.c 1624597 
>   proton/trunk/proton-c/src/codec/data.h 1624597 
> 
> Diff: https://reviews.apache.org/r/25590/diff/
> 
> 
> Testing
> -------
> 
> correctness test:    did ctest -VV  three times with no fails.
> 
> 
> performance test:   ten repetitions, before change and after change, of my 5 million
message test with proton-engine based C clients.
> 
> 
> result is a 6.15% speedup, with good standard deviation
> T-test says resuts have 1.1% chance of being random.
> 
> 
> timing results:
> 
> before change:    mean 39.15 seconds     sigma 2.78
> after change:     mean 36.74 seconds     sigma 2.02
> 
> two-tailed T-test:  P= 0.011    i.e. 1.1% chance of this happening randomly.
> 
> 
> ( I think I can get more than this, but this fn is definitely the biggest single chunk,
so I would like you to review just this one for now.   Any reason not to do this?   )
> 
> 
> I am using callgrind data from a 100,000 message test to find most-called functions,
with significant CPU usage, then looking at code to see which of those are small enough to
(I hope) reasonably inline.
> 
> 
> Thanks,
> 
> mick goulish
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message