new Type[count] takes too much?

John Colvin john.loughran.colvin at gmail.com
Fri Nov 1 02:09:24 PDT 2013


On Friday, 1 November 2013 at 00:16:55 UTC, Namespace wrote:
> On Thursday, 31 October 2013 at 23:48:19 UTC, Jonathan M Davis 
> wrote:
>> On Thursday, October 31, 2013 23:06:22 Namespace wrote:
>>> On Thursday, 31 October 2013 at 09:53:39 UTC, Jonathan M Davis
>>> 
>>> wrote:
>>> > On Thursday, October 31, 2013 10:15:51 Namespace wrote:
>>> >> I'm sure we had already this conversation but I don't find 
>>> >> the
>>> >> thread.
>>> >> 
>>> >> T[] buffer = new T[N]; assumes more space than stated (in
>>> >> average
>>> >> 2010 elements more. See: http://dpaste.dzfl.pl/af92ad22c). 
>>> >> It
>>> >> behaves exactly like reserve and that is IMO wrong. If I
>>> >> reserve
>>> >> memory with buffer.reserve(N), I want to have at least N
>>> >> elements. That behaviour is correct. But if I use new T[N] 
>>> >> I
>>> >> mostly want exactly N elements and no extra space.
>>> >> 
>>> >> Thoughts?
>>> > 
>>> > You're making the assumption that it would be normal to not
>>> > want to then
>>> > append to something you allocated with new T[N], and I don't
>>> > think that that's
>>> > a valid assumption.
>>> 
>>> I disagree. If I want to append I use reserve and I think 
>>> that is
>>> the most common approach.
>>
>> I would fully expect that most people don't bother with 
>> reserve or capacity
>> and that they simply create the array at whatever size they 
>> create it at and
>> then append to it without worrying about reserve. But we'd 
>> have to get real
>> data on that to know for sure one way or the other.
>>
>> Certainly, most folks who are focusing on append performance 
>> seem to use
>> Appender, and for the most part, I would suggest that anyone 
>> using reserve
>> should be using Appender instead.
>>
>> - Jonathan M Davis
>
> Currently Appender isn't more performant than built-in arrays. 
> ;)

I have found it more performant. A sensible test case where it is 
slower should be filed as a bug.


More information about the Digitalmars-d-learn mailing list