Re: Review Request 25590: six percent speedup from inlining one function.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25590/#review53386 --- Ship it! Ship It! - Alan Conway 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.011i.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
Review Request 25590: six percent speedup from inlining one function.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/25590/ --- 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.011i.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
Re: Review Request 25590: six percent speedup from inlining one function.
--- 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.011i.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
