Discussion on Go and D

[Manu]

On 7 April 2012 19:04, Dmitry Olshansky <dmitry.olsh at gmail.com> wrote:

> On 07.04.2012 18:43, Rainer Schuetze wrote:
>
>>
>>
>> On 4/7/2012 8:24 AM, Dmitry Olshansky wrote:
>>
>>> On 07.04.2012 2:08, Rainer Schuetze wrote:
>>>
>>>>
>>>>
>>>> On 4/6/2012 8:01 PM, Walter Bright wrote:
>>>>
>>>>> On 4/6/2012 10:37 AM, Rainer Schuetze wrote:
>>>>>
>>>>>> I hope there is something wrong with my reasoning, and that you could
>>>>>> give me
>>>>>> some hints to avoid the memory bloat and the application stalls.
>>>>>>
>>>>>
>>>>> A couple of things you can try (they are workarounds, not solutions):
>>>>>
>>>>> 1. Actively delete memory you no longer need, rather than relying on
>>>>> the
>>>>> gc to catch it. Yes, this is as unsafe as using C's free().
>>>>>
>>>>
>>>> Actually, having to deal with lifetime issues myself takes away the
>>>> biggest plus of the GC, so I am a bit reluctant to do this.
>>>>
>>>>
>>> How about this:
>>> http://blog.thecybershadow.**net/2010/07/15/data-d-**
>>> unmanaged-memory-wrapper-for-**d/<http://blog.thecybershadow.net/2010/07/15/data-d-unmanaged-memory-wrapper-for-d/>
>>>
>>>
>>>
>>> Or you can wrap-up something similar along the same lines.
>>>
>>>
>> Thanks for your and other's hints on reducing garbage collected memory,
>> but I find it hard to isolate larger blocks of memory for manual
>> management. Most of the structs and classes are rather small.
>>
>>
> Then clearly you need a custom allocator/allocation scheme. Most likely a
> mark/release or a free list kind of thing. Like say TempAlloc by David. As
> standard allocator design is still in motion you'd have to do your own
> thing ATM.
>
> Parsers and lexers are notable examples where doing custom allocation pays
> off nicely.
>
>
>  I'm rather unhappy to sell D with the hint "Go back to manual memory
>> management if you need more than 64MB of memory and want your
>> application to be responsive."
>>
>
> I totally understand this sentiment, and unless GC improves by an order of
> magnitude it is not going to work well with large to medium-scale apps.
> Particularly long running ones, I once had been running VisualD for about
> 16 hours straight (back in the days of GSOC 2011) ;)


Yeeesss.. I run VisualD for days at a time, and it just leaks memory until
my computer chokes and crashes.
It hovers between 1gb and 2gb usage under 'normal' usage for me, on a
relatively small project (only 20-ish files).
I am now in the habit if killing and restarting it regularly, but that's
clearly not a good sign for real-world D apps...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120407/73404537/attachment-0001.html>