[PATCH] Improve string::clear() performance

[Jonathan Wakely]

On 14/09/16 18:28 +0100, Jonathan Wakely wrote:
>On 14/09/16 09:09 -0700, Cong Wang wrote:
>>On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>On 13/09/16 11:02 -0700, Cong Wang wrote:
>>>>
>>>>In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
>>>>_M_mutate(), which could allocate memory as we do COW. This hurts
>>>>performance when string::clear() is on the hot path.
>>>>
>>>>This patch improves it by using _S_empty_rep directly when
>>>>_GLIBCXX_FULLY_DYNAMIC_STRING is not enabled. And Linux distro like
>>>>Fedora doesn't enable this, this is why we caught it.
>>>>
>>>>The copy-and-clear test shows it improves by 50%.
>>>>
>>>>Ran all testsuites on Linux-x64.
>>>
>>>
>>>Thank you for the patch (and changelog and test results!).
>>>
>>>Do you have a GCC copyright assignment in place? See
>>>https://gcc.gnu.org/contribute.html#legal for details.
>>
>>Oh, didn't notice this, I thought gcc has something as quick
>>as the 'Signed-off-by' for Linux kernel (I am a Linux kernel developer).
>>I will do it.
>>
>>>
>>>If I understand the purpose of the change correctly, it's similar to
>>>https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00278.html - is that
>>>right?
>>>
>>
>>Oh, yes, I didn't know your patch because I don't subscribe
>>gcc mailing list. I am wondering why your patch is not merged
>>after 2+ years?
>
>As I said in the patch email, I'm not sure if it's conforming, due to
>clearing the string's cpacity() as well as its size().
>
>>Please let me know what you prefer: 1) You update your patch
>>and get it merged; 2) Use my patch if it looks good. I am fine with
>>either way. :)
>
>I'll refresh my memory of the various issues and reconsider applying
>my patch (that way we don't need to wait for your copyright
>assignment). The performance benefits you measured make it more
>compelling.

I'm applying this patch, which is my one from 2014 with a check for
whether the string is shared, so we just set the length to zero (and
don't throw away reusable capacity) when it's not shared.

Tested x86_64-linux, committed to trunk.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 7292 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20160923/6c5872a1/attachment.bin>