incubator-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 Mon, 06 Aug 2007 03:28:30 GMT
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
View raw message