This is the mail archive of the
mailing list for the libstdc++ project.
Re: [libstdc++ PATCH/RFC] Aggressive space optimization for std::vector
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
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
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
(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.