Re: Why not optimize _Destroy for non-standard allocators, too?

[chris jefferson <caj at cs dot york dot ac dot uk>]

KHO,THOMAS WIN wrote:

>In stl_construct.h in gcc 4.1, _Destroy puts extra effort to check that
>the standard allocator is used before optimizing for types that have
>trivial destructors.
>
>This behavior is described by the code comment:
>   * Destroy a range of objects using the supplied allocator.  For
>   * nondefault allocators we do not optimize away invocation of
>   * destroy() even if _Tp has a trivial destructor.
>
>In a benchmark that uses a custom allocator that reflects a large
>application, we found over a 1% improvement after allowing the same
>optimization for non-default allocators. For us, this speedup comes from
>faster calls to vector::clear().
>
>What's the intention for not optimizing this function for non-default
>allocators?
>
>  
>
The short answer is I don't think we can. We assume that for
std::allocator we that allocator.destroy and allocator.construct just
call placement new and operator delete, and for basic types we don't
have to call them at all. A general allocator could in theory do
whatever it likes in these functions and we can't just ignore that

I have a basic implementation on my computer of adding a new class
called trivial_allocator<T>, which can be overloaded for both the
allocators in the library and user's own allocators which says we can
make these assumptions. However, I'm hoping that eventually g++ is going
to get around to doing empty loop removal (it's already done for some
loops, see bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23361 for the
current status on getting it to work with loops which go over pointers,
although that bug is just new).

If this bug gets fixed, the empty loopw ill be compiled away, and it
will be possible to also remove the existing specialisation, and a few
other similar "specialise a function empty instead of having an empty
loop" things around the place. If however it looks like the loop removal
isn't going to get fixed, I'll look into getting this code neatened up
and submitted. It would be much nicer to do it properly rather than
adding more specialisations to get around the compiler's optimisation
problems.

Chris