Boost logo

Boost :

Subject: Re: [boost] [function] function wrapping withnoexceptionsafetyguarantee
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-11-06 17:31:37

On 11/6/2010 10:22 AM, Daniel Walker wrote:
> On Tue, Nov 2, 2010 at 7:20 PM, Jeffrey Lee Hellrung, Jr.
> <jhellrung_at_[hidden]> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at