stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] for STDCXX-491 - string::push_back() slow
Date Tue, 07 Aug 2007 15:35:14 GMT
Mark Brown wrote:
> Neat graph! What software did you use to create it?

gnuplot: http://www.gnuplot.info/

> 
> I'm also curious about the precipitous drop in the performance of both stdcxx and stlport
around 32 elements. Do you have an explanation for it?

I was going to say that string in stdcxx reaches its initial
capacity at 32 characters and needs to be reallocated, but
now that I've checked the source code I see that the value
of _RWSTD_MINIMUM_STRING_CAPACITY is 128, so that can't be
it. I don't see the same pattern in the graph on Solaris
(attached) where there is a dip around 128 as expected so
I wonder if it's a function of the allocator in glibc.

Martin

> 
> -- Mark
> 
> 
>> -----Original Message-----
>> From: sebor@roguewave.com
>> Sent: Sun, 05 Aug 2007 21:28:30 -0600
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: [PATCH] for STDCXX-491 - string::push_back() slow
>>
>> Looks like ezmlm stripped the grap attached to my previous post so
>> I attached it to the issue instead:
>>
>> http://issues.apache.org/jira/secure/attachment/12363211/push_back.png
>>
>> Martin
>>
>> Martin Sebor wrote:
>>> FWIW, I've benchmarked the latest push_back() against stdcxx 4.1.3
>>> and a number of other implementations, including STLport 5.1.3. We
>>> are faster than any other implementation except STLport, and close
>>> to STLport in the general case. STLport has an advantage for short
>>> strings (less than 16 characters), most likely because of the short
>>> string optimization.
>>>
>>> Martin
>>>
>>> Martin Sebor wrote:
>>>> Farid Zaripov wrote:
>>>>>> -----Original Message-----
>>>>>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin
>>>>>> Sebor
>>>>>> Sent: Tuesday, July 24, 2007 7:40 AM
>>>>>> To: stdcxx-dev@incubator.apache.org
>>>>>> Subject: Re: [PATCH] for STDCXX-491 - string::push_back() slow
>>>>>>
>>>>>> mark.g.brown wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> The attached simple patch speeds up push_back() nearly six times
>>>>>>> relative to stdcxx 4.1.3 and makes it more than twice faster
that
>>>>>>> gcc's.
>>>>>> Let me test your patch for regressions and if it passes I'll commit
>>>>>> it tomorrow.
>>>>>   I see the difference between the old push_back() behavior and after
>>>>> this patch.
>>>>> The append (size_type (1), __c); also appends terminating NULL
>>>>> character
>>>>> (string.cc, line 472). Below is the corrections to the patch:
>>>> Ah, yes, good catch!
>>>>
>>>> On the subject of the terminating NUL, I wonder it would simplify
>>>> (and speed up) the implementation if we appended the terminating
>>>> NUL in c_str() instead in every modifying member function. We'd
>>>> still need to allocate enough memory for it because c_str() isn't
>>>> allowed to invalidate iterators, pointers, and references into
>>>> the object but we might be able to save ourselves a few CPU
>>>> cycles if we set data()[size()] to charT() only in c_str().
>>>>
>>>> Hmmm, something to think about...
>>>>
>>>> Martin
>>>>
>>>>>>>  template <class _CharT, class _Traits , class _Allocator>
 inline
>>>>>>> void basic_string<_CharT, _Traits, _Allocator>::
>>>>>>> +push_back (value_type __c)
>>>>>>> +{
>>>>>>> +    const size_type __size = size () + 1;
>>>>>>> +
>>>>>>> +    if (   capacity () < __size
>>>>>>> +        || size_type (1) < size_type (_C_pref ()->_C_get_ref
()))
>>>>>>> +        append (1, __c);
>>>>>>> +    else {
>>>>>>> +        traits_type::assign (_C_data [size ()], __c);
>>>>>                 // append the terminating NUL character
>>>>>                 traits_type::assign (_C_data [__size], value_type ());
>>>>>>> +        _C_pref ()->_C_size._C_size = __size;
>>>>>>> +    }
>>>>>>> +}
>>>>> Farid.
>>>>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message