On 11/6/2010 10:22 AM, Daniel Walker wrote:
On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
On 11/02/2010 02:50 PM, Daniel Walker wrote: [...]
Here are the results I got, again, using the build of g++ 4.2 provided by my manufacturer.
Data (Release): | function | function (static empty) time/call | 3.54e-07s | 3.51e-07s space/type | 64B | 80B
Data (Debug): | function | function (static empty) time/call | 2.05e-06s | 2.04e-06s space/type | 64B | 80B
You can see that removing the empty check from boost::function yields about a 1% improvement in time per call to boost::signal. The increased space per type overhead is the same as before: 16B.
[...]
[Butting in after only vaguely following this thread...]
Would it also be appropriate to measure the "space/call", in addition to "time/call" and "space/type"? Or is there no difference, or had this been addressed already?
Well, a call to boost::function does not cost any additional space.
I'm not sure what you mean. "Additional" to what? Isn't the underlying dispatching code different for the 2 implementations of boost::function you're comparing above? I.e., one has a null-pointer check, while the other doesn't. One might hypothesize that the dispatching code that must perform a null-pointer check will compile to more instructions than the dispatching code that does not perform a null-pointer check, and I presume the timings above support this hypothesis. I would think this should lead to variations in the size of the code segment. This variation might be more pronounced if the dispatching were inlined. I'm just speculating... - Jeff