On Sat, Nov 6, 2010 at 5:31 PM, Jeffrey Lee Hellrung, Jr. <jhellrung@ucla.edu> wrote:
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?
In addition to not calling boost::function. All of the additional space overhead is incurred when boost::function is instantiated (and assigned). No additional space overhead is incurred when an instantiated object is called at runtime, though of course the call does take up space for code in the text segment.
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...
Yes, the text segment size also changes. And in fact, I believe, we could move the space overhead in the data segment to the text segment by making the static initialized vtable constant, as was suggested earlier in this thread. So, the text segment size could be more important in determining the expense of the static empty scheme. Daniel Walker