On Saturday, 6 February 2021 at 19:13:33 UTC, Mike Parker wrote:
> On Saturday, 6 February 2021 at 17:50:18 UTC, frame wrote:>
>
>> But .length = 0 should.
>>
>
> What do you expect it to do in this case?

Don't know - some compiler optimization? :D


On Saturday, 6 February 2021 at 19:31:39 UTC, Siemargl wrote:

> 64bit heal a problem, but uses about 500Mb of RAM continuosly for this simple example, so its only patching sinkin' ship :-(

Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really marked as private bytes. Constant. If I use GC.minimize() it goes up and down and sometimes consumes more than 203 MB. Best is 100MB. But it doesn't leak endlessly like the 32bit variant.

On Saturday, 6 February 2021 at 20:24:00 UTC, frame wrote:

> Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really marked as private bytes. Constant. If I use GC.minimize() it goes up and down and sometimes consumes more than 203 MB. Best is 100MB. But it doesn't leak endlessly like the 32bit variant.

Update:

Thanks to Adam's bug report:
https://issues.dlang.org/show_bug.cgi?id=21550

My poorly delivered example modified foo() runs also smooth on 32bit now:

>void foo() {
>    string[] s;
>
>    foreach (i; 0 .. 50_000_00) {
>        s ~= "a";
>    }
>		
>    // GC.free(s.ptr);
>    GC.free(GC.addrOf(s.ptr));
>}

I think the automatic GC is also affected by this issue.

On Tuesday, 9 February 2021 at 04:05:04 UTC, frame wrote:
> On Saturday, 6 February 2021 at 20:24:00 UTC, frame wrote:
>
>> Hmmm.. with -m64 it's reporting 80 MB used, 203 MB are really marked as private bytes. Constant. If I use GC.minimize() it goes up and down and sometimes consumes more than 203 MB. Best is 100MB. But it doesn't leak endlessly like the 32bit variant.

Hmm, I try to rewrite example in C# and it just hangs in GC, when str += "1" added 5 million times.

Then i fix this using StringBuilder, as documented. It works fine.

Next i searched flang forums for D's StringBuilder - found this
https://forum.dlang.org/post/l667ab$cfa$1@digitalmars.com

auto strBuilder = appender!string;
foreach (i; 0 .. 50_000_00) {
   strBuilder.put("a");

And it works too, for 32-bit also =)
Consuming about 100MB RAM.

On Saturday, 13 February 2021 at 17:54:53 UTC, Siemargl wrote:

> And it works too, for 32-bit also =)
> Consuming about 100MB RAM.

Yes, Appender is nice but I had no control about .data since the real property is private so I chose that edgy example to find the problem with the GC.

As someone mentioned before, in a real application you would choose some pre-allocation like reserve() on Appender instead which performs better.

On Saturday, 13 February 2021 at 19:14:32 UTC, frame wrote:
> On Saturday, 13 February 2021 at 17:54:53 UTC, Siemargl wrote:
>
>> And it works too, for 32-bit also =)
>> Consuming about 100MB RAM.
>
> Yes, Appender is nice but I had no control about .data since the real property is private so I chose that edgy example to find the problem with the GC.
>
> As someone mentioned before, in a real application you would choose some pre-allocation like reserve() on Appender instead which performs better.

LDC 1.24 is unaffected of this bug and x64 target consume less memory.