Re: [PATCH] improve performance of std::allocator::deallocate

On 04/02/2019 07:33 PM, Padraig Brady wrote: > On 03/07/2019 03:43 AM, Jonathan Wakely wrote: >> OK, that makes me feel better about it. It's presumably much easier to >> upgrade to 5.2 from 5.0 or 5.1 than it would be from 4.x. >> How complicated is the fix to prevent the crashes? Would

Re: [PATCH] improve performance of std::allocator::deallocate

On 03/07/2019 03:43 AM, Jonathan Wakely wrote: > On 06/03/19 22:27 +0000, Pádraig Brady wrote: >> >> >> On 03/06/2019 01:44 AM, Jonathan Wakely wrote: >>> On 06/03/19 09:20 +, Pádraig Brady wrote: >>>> On 03/06/2019 12:50 AM, Jonathan Wakely wro

Re: [PATCH] improve performance of std::allocator::deallocate

On 03/06/2019 01:44 AM, Jonathan Wakely wrote: > On 06/03/19 09:20 +0000, Pádraig Brady wrote: >> On 03/06/2019 12:50 AM, Jonathan Wakely wrote: >>> On 06/03/19 02:43 +0000, Pádraig Brady wrote: >>>> >>>> >>>> On 02/26/2019 04:23 PM,

Re: [PATCH] improve performance of std::allocator::deallocate

On 03/06/2019 12:50 AM, Jonathan Wakely wrote: > On 06/03/19 02:43 +0000, Pádraig Brady wrote: >> >> >> On 02/26/2019 04:23 PM, Padraig Brady wrote: >>> >>>> Note jemalloc >= 5.1 is required to fix a bug with 0 sizes. >>>> >>>>

Re: [PATCH] improve performance of std::allocator::deallocate

On 02/26/2019 04:23 PM, Padraig Brady wrote: > >> Note jemalloc >= 5.1 is required to fix a bug with 0 sizes. >> >> How serious is the bug? What are the symptoms? >> > I've updated the commit summary to say it's a crash. > Arguably that's better than mem corruption. > >> It looks like 5.1.0 is

Re: [PATCH] improve performance of std::allocator::deallocate

On 02/26/2019 05:50 AM, Jonathan Wakely wrote: > On 23/02/19 02:04 +0000, Pádraig Brady wrote: >> Attached is a simple patch which has been extensively tested within >> Facebook, >> and is enabled by default in our code base. >> >> Passing the size to th

[PATCH] improve performance of std::allocator::deallocate

Attached is a simple patch which has been extensively tested within Facebook, and is enabled by default in our code base. Passing the size to the allocator allows it to optimize deallocation, and this was seen to significantly reduce the work required in jemalloc, with about 40% reduction in CPU

Re: Disabling warn_unused_result warnings on a case-by-case basis

On 14/06/16 10:32, Florian Weimer wrote: A long time ago, GCC decided that warn_unused_result warnings should *not* be silenced by casting to void, as in: (void) write (STDOUT_FILENO, message, strlen (message)); Apparently, programmers have figured out to use this idiom as a replacement:

regression in C++ parsing performance between 4.9.3 and 5.3.1

The attached shell script will generate a larger version of the following: constexpr bool static_str_equal(const char* x, const char* y) { return (*x == 0 || *y == 0) ? (*x == *y) : ((*x == *y) && static_str_equal(x + 1, y + 1)); } int main(void) { static_assert(

-Wmissing-field-initializers relaxation request

While trying to compile coreutils with -Wextra, I noticed many warnings due to automatic variables initialized with { 0, }. As I understand it, since C90 the above will initialize [all members of] the type to that used in static scope. I.E. the following is valid: mbstate_t m = { 0, }; int i =