Steve Schveighoffer wrote:
> On Sat, 06 Jun 2009 21:59:39 -0700, Sean Kelly wrote:
> 
>> Steve Schveighoffer wrote:
>>> On Sat, 06 Jun 2009 12:03:03 -0700, Sean Kelly wrote:
>>
>> auto str1 = "hello".idup;
>> auto str2 = str3 = str1;
>> str2 ~= " world";
>> str3 ~= " garbage";
>>
>> Doesn't seem terribly safe to me.
> 
> Oh, I know.  It's a long-standing issue with immutability, but I think if appending gets fixed as Andrei suggests, this should be fixed as well.  I was just saying that your statement about immutable data never being appended in-place was false.

Oops, I replied based on an educated guess--I should have tested it. Still, immutable arrays are hardly immutable if an append can alter their contents.

Fawzi Mohamed wrote:
> On 2009-06-07 10:47:47 +0200, Christian Kamm <kamm-incasoftware@removethis.de> said:
> 
>> bearophile wrote:
>>
>>>> The following code even crashes LDC during the compilation, I'll ask in
>>>> the LDC channel:<
>>>
>>> The good ChristianK has already added it:
>>> http://www.dsource.org/projects/ldc/ticket/320
>>
>> And thankfully Frits van Bommel has already fixed it: it consumes about 40kb
>> of heap memory at runtime now.
>>
>> This seems to be because we don't use the _d_arrayappend functions at all
>> but emit a _d_arraysetlength instead. What's the memory growing behavior of
>> that function? Should this be considered a bug?
> 
> I would say that setlength should not allocate extra space, because one should trust that the user knows his needs

char[] x;
x.length = 100; // setlength allocates memory

On 2009-06-08 15:55:26 +0200, Sean Kelly <sean@invisibleduck.org> said:

> Fawzi Mohamed wrote:
>> On 2009-06-07 10:47:47 +0200, Christian Kamm <kamm-incasoftware@removethis.de> said:
>> 
>>> bearophile wrote:
>>> 
>>>>> The following code even crashes LDC during the compilation, I'll ask in
>>>>> the LDC channel:<
>>>> 
>>>> The good ChristianK has already added it:
>>>> http://www.dsource.org/projects/ldc/ticket/320
>>> 
>>> And thankfully Frits van Bommel has already fixed it: it consumes about 40kb
>>> of heap memory at runtime now.
>>> 
>>> This seems to be because we don't use the _d_arrayappend functions at all
>>> but emit a _d_arraysetlength instead. What's the memory growing behavior of
>>> that function? Should this be considered a bug?
>> 
>> I would say that setlength should not allocate extra space, because one should trust that the user knows his needs
> 
> char[] x;
> x.length = 100; // setlength allocates memory

I thought it was clear that I meant that (apart some rounding up done by the gc), the allocation created by x.length should no allocate *extra* space (meaning more that needed), because it is quite clear that the user wants that much space, and the likelihood that he doesn't really know, and some extra space would be good is not so high.
Thus adding space would most likely be wasted.

If the user appends to an array, and reallocation is needed on the other hand, the probability that that array will be appended again is much higher, so it makes sense to allocate some extra space. This makes continuously appending to an array perform O(log(N)) reallocations.

In any case I fixed the newCapacity function in tango, with one of my guesses for a good function.
But if anybody comes with some benchmarks that suggest and improvement I will gladly do it.

Fawzi