Re: [boost] [utility] new auto_buffer class --- RFC

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-03 14:58:02

Peter Dimov skrev:
> Thorsten Ottosen:
>> Christopher Jefferson skrev:
>>>
>>> On 2 Mar 2009, at 21:32, Thorsten Ottosen wrote:
>>
>>>> So did I in a real-time ray-tracing application. The difference was 
>>>> a deal-breaker.
>>>>
>>>
>>> Interesting, I wouldn't have expected to get such a big difference. I 
>>> certainly have no trouble with a push_back_unchecked(), but think 
>>> push_back() should do what it does in vector and friends.
>>
>> Right.
> 
> The reason for the apparent discrepancy is probably because Thorsten is 
> comparing Dinkumware's vector::push_back against his unchecked 
> auto_buffer::push_back, and erroneously attributing the difference in 
> performance to the fact that push_back is not inlined (false; push_back 
> itself is easily inlined by all compilers I know of) and to the presence 
> of the capacity check.
> 
> In fact, the problem lies in the Dinkumware implementation of push_back, 
> not in the interface requirements. Here's the older version (VC6):
> 
> void push_back(const _Ty& _X)
>  {insert(end(), _X); }
> 
> Why this underperforms should be obvious.
> 
> Here's the more recent version (VC7.1-9.0):
> 
> void push_back(const _Ty& _Val)
>  { // insert element at end
>  if (size() < capacity())
>   _Mylast = _Ufill(_Mylast, 1, _Val);
>  else
>   insert(end(), _Val);
>  }
> 
> This is somewhat better, but still suboptimal, for two reasons. One, it 
> diligently goes through Alloc::construct, using two nested function 
> calls for that; two, size() and capacity() hide two divisions on sizeof(T).
> 
> Changing the implementation to check for _Mylast < _Myend and inlining 
> the _Ufill call by hand improves the performance of 
> vector<int>::push_back dramatically, and the unchecked version no longer 
> has any significant advantage.

Thanks for the analysis.

But don't you agree that is is worth avoiding the check for the buffer 
being full when this is possible?

-Thorsten