Re: [libstdc++ PATCH/RFC] Aggressive space optimization for std::vector

[Doug Gregor <dgregor at apple dot com>]

On Monday, July 28, 2003, at 1:16PM, Nathan Myers wrote:

> On Mon, Jul 28, 2003 at 12:52:31PM -0700, Doug Gregor wrote:
> > The attached patch implements an aggressive space optimization for
> > vector, where we share a bit of the vector code for a POD type with 
> > all
> > other POD types with the same size/alignment. ...
> >
> > ... I'd like to know if this type of optimization is
> > desired in libstdc++. It uglifies the source a bit, but it can be a
> > boon to users.
>
> The amount saved for vector, by itself, doesn't seem worth the
> obfuscation, but I assume this patch is practice for (e.g.) _Rb_tree,
> where the member algorithms are much more substantial, and the savings
> proportionally more valuable.

This really is it, except for perhaps std::list or std::deque; most of 
the shareable _Rb_tree code has already been split out by Gawain, and 
the type of optimization I'm proposing won't help for associative 
containers.

> Usually, when the subject arises, it turns to getting the linker to
> recognize functions that result in the same sequence of object code,
> equating them, and throwing away the extra copies.  Is there any
> prospect of Apple improving the linking process, instead?  (And, in
> a way that helps gld systems too?  Does macosix use a BSD linker or
> GNU ld?)

(1) Not that I know of. (2) Doubtful. (3) Neither.
I don't think it's a bad idea to do this in the linker (and I certainly 
don't want to rehash any previous discussions on the matter), but I do 
wonder if the linker will catch all of the cases. Will GCC produce 
similar enough code for int and float? For an arbitrary POD type? I 
don't know, but I do know we can do a pretty good job at the library 
level, and we can have it now on all platforms.

	Doug