MIT Technology Review: An Interview With Bjarne Stroustrup

[Dave]

Sean Kelly wrote:
> Pragma wrote:
>> zz wrote:
>>>
>>> Conclusions:
>>> D is great, but DMD will have to do something about it's performance 
>>> for some applications.
>>
>> I tend to agree.  D's array allocation algorithm, as well as it's GC 
>> behavior, are great for most cases.  But they can fall flat in certain 
>> cases - of course that's true of any algorithm really. :)
>>
>> While I'm no STL guru, I have to ask: which allocator were you using 
>> with ptr_vector?
>>
>> I know that with D, pre-allocating data for arrays can make a big 
>> difference if you expect to perform a lot of concatenations - 
>> especially with atomic elements like pointers or references.
> 
> I still find this confusing.  The GC uses "power of two" sized blocks up 
> to page size where the grow strategy kicks in, so it should already be 
> using "double my current size" allocation behind the scenes.  But I 
> suppose I should really spend some time testing this to see if it can be 
> improved.  One slightly crazy idea that's been kicked around is to allow 
> the user to override the default grow strategy, but that only seems 
> useful if the default one really isn't appropriate for most situations, 
> and I'm hoping that testing plus perhaps some tweaks to the algorithm 
> will obviate the need for this.
> 

If concatenating to the vector is the bottleneck, they may have been concatenating to the D 'vector' 
with arr = arr ~ elem; instead of arr ~= elem;? In that case it wouldn't be preallocating, but 
creating a bunch of temporaries.

Just a guess.

If that's the case, wouldn't if be pretty 'easy' and safe to optimize the built-in?

> 
> Sean