Re: [boost] Re: New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-29 06:36:46

In message <8vtun3+b6p9_at_[hidden]>, 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.

>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? ;->

>> 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.

>> 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? 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.

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

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________