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
> >> 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
> >the ref-counted object may do a thousand allocations internally
> >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
> 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
> >> with vptr + sizeof(funcobj)) of a cloning version is lower than
> >that of
> >> the detached reference-counted version. [Aside: This would be
> >> for countable_ptr, http://www.boost.org/more/count_bdy.htm,
> >> get round to Boostifying at some point.]
> >This *may* be important. It all depends on whether speed or size
> >more important to your optimizations. Even your countable_ptr
> >pay attention to this, because there's still an additional
> >type for the ref-count involved.
> It *is* important if the intent of an optimisation is to optimise.
> and size are neither perfectly orthogonal nor always inversely
> Allocating, say, a large object x and a small object y takes more
> 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
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
> >> counting as an optimisation as it has proved to be awkward and
> >> always an optimisation. For instance, the standard basic_string
> >> effective reference counting awkward, and often a waste of
> >The reasons why don't apply here, however. They are hardly
> >reasons. For one thing, basic_string implementations have to be
> >not just RC. The COW attribute can result in performance actually
> >degrading for some uses. Further, COW causes some tricky
> >with iterators and similar functionality of basic_string that
> >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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk