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

[Doug Gregor]

On Monday, July 28, 2003, at 1:13PM, Gabriel Dos Reis wrote:

> Doug Gregor <dgregor@apple.com> writes:
>
> | There is more that can be done on the micro-optimization level, such
> | as eliminating some of the extra overhead in _Vector_impl (e.g., its
> | iterators can just be pointers, because they will never be exposed to
> | the user). However, 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.
>
> I guess this space optimization may have some impact on code
> efficiency (optimization for something else than space).  Did you make
> any measurements? I'm worried because GCC currently tends not to
> inline even simple accessor -- see past report by Benjamin.

It could have some impact on code efficiency (the deeper call graph and 
replacement of fundamental types with class types are two potential 
problems), but I haven't measured this. As I mentioned previously, the 
patch does introduce code size regressions (albeit small ones) in the 
no-reuse case, so we are likely losing a little performance here. I'll 
look to see if I can stamp out those regressions, perhaps by moving 
away from _Basic_pod.

>  Try to
> compile with -Winline.

No difference.

> It would be nice if this code was rather controlled by -Os.

It's an ABI-breaker, so we can't do that.

> Also, I suppose this
>
> !
> !   // Primary template has maximum alignment
> !   template<std::size_t _Alignment>
> !     struct _Type_with_alignment
> !     { struct __attribute__((__aligned__)) _M_type {}; };
> !
> ! #define _GLIBCXX_TYPE_WITH_ALIGNMENT(_Align)				\
> !   template<>								\
> !     struct _Type_with_alignment<_Align> \
> !     { struct __attribute__((__aligned__(_Align))) _M_type {}; }
>
> is for getting around the bug in how attributes are handled (I filled
> a bug report on that a while ago), i.e. attributes don't respect usual
> name lookup rules.  Please add a note to that effect.

I'd really like:
   template<std::size_t _Alignment>
     struct __attribute__((__aligned(_Alignment))) _Type_with_alignment 
{};

... but I've just added a note instead.

> Also, I would rather see
>
> ! template<std::size_t _Size, std::size_t _Alignment>
> !   struct __type_traits<std::_Basic_pod<_Size, _Alignment> >
> !   {
> !     typedef __true_type    has_trivial_default_constructor;
> !     typedef __true_type    has_trivial_copy_constructor;
> !     typedef __true_type    has_trivial_assignment_operator;
> !     typedef __true_type    has_trivial_destructor;
> !     typedef __true_type    is_POD_type;
> !   };
>
> in the file where the original __type_traits<> is defined.

Ok.

>   In the
> long run, we should move away from the type based __true_type usage
> toward integral constant usage.

We should move to the TR type traits proposal, I think.

	Doug