Re: BCB5, the pimpl idiom bug and the new Unit Test Framework

From: edbrey (edbrey_at_[hidden])
Date: 2001-12-23 09:59:56

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:

> > Not so fast.  Containers don't directly contain scoped_ptrs,
> > but they can contain them indirectly (e.g. contain pointers
> > to objects that house them).  It is not uncommon to have
> > lots of a smallish, noncopyable class that would use
> > scoped_ptr.  Even given heap overhead, increasing the size
> > of scoped_ptr can make a big difference in overall memory
> > used.
> 
> Do you have a concrete example of a real-world project where
> increasing the size of scoped_ptr from 4 to 8 makes a big
> difference?

Have I measured a big difference?  No.  That's because the project 
I'm working on, where I use the above pattern hasn't gotten to the 
profiling/optimization stage.  It's also because the current 
scoped_ptr is nice and lean, and I don't have reason to experiment 
with it. :)  The scenario is a collection of objects representing 
devices on an industrial network.  During the initial stages of a 
device's life and only during occasional bursts thereafter, I need to 
store extra data to keep track of progress of a special transaction, 
hence the scoped_ptr.  Without the transacion data, the data needed 
to represent is quite small, around 40 bytes.  Some use cases call 
for working with thousands of devices at once, in cases where they 
have little information to transmit on a regular basis (such as with 
ciruit breakers).

This raises the following concerns:
- memory: in an embedded device, such as one summarizing the 
networks' devices into a web page (or other standard format that I 
won't go into here), low hardware cost is desirable.  To make matters 
worse, the memory problem is stochastic, rather than linear, since 
the device object is created on the heap and the scoped_ptr bloat 
might push the object size past onto the an allocation size boundary 
and so would increase memory use by more than just 10%, in this case.

- speed: As the memory map gets padded out, one can expect more cache 
misses, since the cache block is now filled with padding, rather than 
other useful object data.

I'll readily admit that this is not a show-stopper example.  The 
losses are not outrageous; OTOH, IHMO the gains of bundling pimpl 
into scoped_ptr are much smaller.  Plus I'm just one programmer and 
this is just one example.  Additionally, I think the following 
argument puts the lean scoped_ptr over the top:

The worst aspect of these two types or performance loss is that 
neither is easy to detect during profiling.  In neither case will one 
likely see a hot spot generated, but rather there will be a general 
penalty that will just fall into the apparent baseline cost of 
getting the job done.

The only real way to profile is to remember that scoped_ptr is 
bloated, recode it with a regular pointer (or write your own 
scoped_ptr), and compare test results.  However, the cost of doing so 
is much greater than the benefit of using scoped_ptr in the first 
place.  Basically, scoped_ptr would become relegates to stack-based 
usage, and cases where the programmer _knows_ that there won't be a 
performance problem.