[Bug libstdc++/64128] New: Let vector take advantage of malloc_usable_size for malloc-using allocators

[Bug libstdc++/64128] New: Let vector take advantage of malloc_usable_size for malloc-using allocators

[gcc-bugzilla at contacts dot eelis.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128

            Bug ID: 64128
           Summary: Let vector take advantage of malloc_usable_size for
                    malloc-using allocators
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc-bugzilla at contacts dot eelis.net

Created attachment 34150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34150&action=edit
testcase

Changing

  this->_M_impl._M_end_of_storage = __new_start + __len;

to

  this->_M_impl._M_end_of_storage = __new_start +
      malloc_usable_size(__new_start) / sizeof(value_type);

in vector.tcc makes the runtime of the attached program drop from 0.35 seconds
to 0.24 seconds on my machine, a 31% reduction.

This shows there is low hanging fruit for a very common operation
(vector::push_back). A proper implementation would of course only do this for
allocators that are known to be malloc frontends. :)

[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators

[gcc-bugzilla at contacts dot eelis.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128

--- Comment #1 from Eelis <gcc-bugzilla at contacts dot eelis.net> ---
Hmm, std::allocator::allocate calls ::operator new, which may be user-defined,
so maybe there is no practical way to detect whether it is really using malloc.
:(

[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Comment on attachment 34150
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34150
testcase

Users can specialize std::allocator so we'd need to use SFINAE hacks to find
out if __gnu_cxx::new_allocator is the base class and if it's unspecialized.

It's a silly test though, if you care about performance there use reserve().

[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators

[gcc-bugzilla at contacts dot eelis.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128

--- Comment #4 from Eelis <gcc-bugzilla at contacts dot eelis.net> ---
Yeah, I noticed that tcmalloc is also way faster, and since tcmalloc barely
over-allocates for the sizes requested by vector, there is no benefit to using
malloc_usable_size (which it also supports) there.

So I think the bottom line is indeed: just don't use glibc malloc, because it's
very slow.