From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-12-05 04:12:54
In message <200012042317.PAA03457_at_[hidden]>, Karl Nelson
>> Could you clarify the size issue? Do you mean sizeof footprint, memory
>> allocated, ...?
>There are three sizes to a program and the design of the system
>affects all 3.
> - static binary size (how much stuff gets compiled into the executable)
> - runtime binary size (how much actually gets loaded)
> - runtime data size (how big are the objects created at run time.)
I tend to split the data view up in terms of
- the sizeof of footprint, eg one pointer vs two pointers
- the number of heap objects associated/owned
- the sizes of the heap objects
The last two -- or even all three, depending on your definition -- could
be said to constitute the 'working set' of the object.
The footprint for a reference counting instance using shared_ptr is the
same as that for cloning. The working set, for a given object, is
larger, but with increased sharing this decreases.
>Of the things in my last summary, here are some the affects
> sharing (reference counting) - reduces runtime data size if many copies
> are used, but increases if things can't be shared as you need extra
> data (counters) This system also potentially increases binary size
> as the counter dealing code may get scattered everywhere. This
> competes against the copy code which we avoided.
> cloning - every copy increases runtime data size, thus if the user copies
> functors frequently, they will get loads of runtime data. Further,
> each of those copied will implement lots of operator=() so you get
> runtime and static binaries which are larger.
I'm not sure that I understand what you mean by operator= being
implemented lots. Both the reference-counted and cloning designs must
implement operator=, but in one case clone is called and in the other
the count is incremented. However, roughly the same amount of code --
which is small -- will be generated in each case for operator=.
Kevlin Henney phone: +44 117 942 2990
Curbralan Limited mobile: +44 7801 073 508
mailto:kevlin_at_[hidden] fax: +44 870 052 2289
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk