On 7 April 2012 19:04, Dmitry Olshansky <[email protected]> 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...
