Re: New New Callbacks Uploaded

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-11-29 10:03:17

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vtun3+b6p9_at_e...>, William Kempf <sirwillard_at_my-
> deja.com> writes
> >> Also don't forget that shared_ptr allocates two objects, so in 
> >theory
> >> you couldn't recover any ROI until your second copy anyway.
> >
> >Help me.  I've not heard the acronym ROI.
> 
> Return on Investment.

Thanks.

> >In any event, the cost of copying is MUCH more than the number of 
> >allocations that must be made.  Not to mention that for all we 
know, 
> >the ref-counted object may do a thousand allocations internally 
when 
> >you copy it.  Even with out knowing precisely what ROI means, it 
> >doesn't sound like you can theorize anything here.
> 
> Why is the cost of copying "MUCH more" than the number of 
allocations
> made? What kind of function objects are you passing around? Are you
> theorising? ;->

Poor wording.  Should have been a "can" or "might" in there 
somewhere.  So, yes, it's theorizing, but accurate even in the real 
world.  The cost of copying an object includes both allocation of 
space (what you pointed out) and initialization of the allocated 
memory (what you left out).  Which of these is the greater cost 
depends completely on what's being copied.  And no, function objects 
aren't exempt from this since they often carry around state 
information that can be expensive to copy either because of numerous 
allocations or complex initialization logic.
 
> >> Also note
> >> that the footprint (single pointer) and working set (single heap 
> >object
> >> with vptr + sizeof(funcobj)) of a cloning version is lower than 
> >that of
> >> the detached reference-counted version. [Aside: This would be 
> >different
> >> for countable_ptr, http://www.boost.org/more/count_bdy.htm, 
which I 
> >must
> >> get round to Boostifying at some point.]
> >
> >This *may* be important.  It all depends on whether speed or size 
are 
> >more important to your optimizations.  Even your countable_ptr 
must 
> >pay attention to this, because there's still an additional 
integral 
> >type for the ref-count involved.
> 
> It *is* important if the intent of an optimisation is to optimise. 
Speed
> and size are neither perfectly orthogonal nor always inversely 
related.
> Allocating, say, a large object x and a small object y takes more 
time
> and uses more space than allocating a single object that is slightly
> larger than x. This is what I was driving at, sorry I wasn't being
> clear.

Well, there's numerous ways to optimize, which still leaves this 
stance as tenuous ;).  No, I do mostly agree with you here, I just 
think there's WAY too much emphasis being put on optimizations in all 
of this talk, with no concrete evidence being given for the need for 
optimization, or more importantly, the type of optimization needed.  
We've left the realm of general, easy to implement, optimizations 
sure to be of benefit and entered the land of micro-optimizations 
that should only be applied for specific cases.
 
> >> More generally, there is a general trend away from hidden body 
> >reference
> >> counting as an optimisation as it has proved to be awkward and 
not
> >> always an optimisation. For instance, the standard basic_string 
> >makes
> >> effective reference counting awkward, and often a waste of 
effort.
> >
> >The reasons why don't apply here, however.  They are hardly 
universal 
> >reasons.  For one thing, basic_string implementations have to be 
COW 
> >not just RC.  The COW attribute can result in performance actually 
> >degrading for some uses.  Further, COW causes some tricky 
situations 
> >with iterators and similar functionality of basic_string that 
really 
> >only apply to a few class types.  None of this applies here.
> 
> Are you suggesting that function objects should be shared as an
> optimisation and yet not use COW?

Emphatically *YES*.  After all, they are emulating function pointers, 
which are shared entities (copy it and they point to the exact same 
entity) but are not COW.  COW wouldn't even make sense here, because 
you *NEVER* write to the instance here.

> This is not an optimisation, this is a
> fundamentally different set of semantics. Sharing is a separate 
issue: I
> copies should be copied not shared; we need a separate class for
> sharing, whether it's shared_ptr or some other proxy class.

This is a valid argument from a different tangent.  I don't agree 
because I'm looking at this from a much different perspective.  If 
you ref-count here COW makes no sense.  So, if you want to argue that 
deep copies are a must (I'm not sure I agree, being on the fence, but 
let's go there) then ref-counting is strictly out here. 

> I suspect that somewhere in here we might be in agreement ;-)

I'm not so sure.  You're still in favor of COW, and frankly I don't 
think that's valid, much less the/a preferred approach here.

Bill Kempf