<div class="gmail_quote">On 7 April 2012 19:04, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com">dmitry.olsh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 07.04.2012 18:43, Rainer Schuetze wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 4/7/2012 8:24 AM, Dmitry Olshansky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07.04.2012 2:08, Rainer Schuetze wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 4/6/2012 8:01 PM, Walter Bright wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4/6/2012 10:37 AM, Rainer Schuetze wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I hope there is something wrong with my reasoning, and that you could<br>
give me<br>
some hints to avoid the memory bloat and the application stalls.<br>
</blockquote>
<br>
A couple of things you can try (they are workarounds, not solutions):<br>
<br>
1. Actively delete memory you no longer need, rather than relying on<br>
the<br>
gc to catch it. Yes, this is as unsafe as using C's free().<br>
</blockquote>
<br>
Actually, having to deal with lifetime issues myself takes away the<br>
biggest plus of the GC, so I am a bit reluctant to do this.<br>
<br>
</blockquote>
<br>
How about this:<br>
<a href="http://blog.thecybershadow.net/2010/07/15/data-d-unmanaged-memory-wrapper-for-d/" target="_blank">http://blog.thecybershadow.<u></u>net/2010/07/15/data-d-<u></u>unmanaged-memory-wrapper-for-<u></u>d/</a><br>
<br>
<br>
<br>
Or you can wrap-up something similar along the same lines.<br>
<br>
</blockquote>
<br>
Thanks for your and other's hints on reducing garbage collected memory,<br>
but I find it hard to isolate larger blocks of memory for manual<br>
management. Most of the structs and classes are rather small.<br>
<br>
</blockquote>
<br></div>
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.<br>

<br>
Parsers and lexers are notable examples where doing custom allocation pays off nicely.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm rather unhappy to sell D with the hint "Go back to manual memory<br>
management if you need more than 64MB of memory and want your<br>
application to be responsive."<br>
</blockquote>
<br></div>
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) ;)</blockquote>
<div><br></div><div>Yeeesss.. I run VisualD for days at a time, and it just leaks memory until my computer chokes and crashes.</div><div>It hovers between 1gb and 2gb usage under 'normal' usage for me, on a relatively small project (only 20-ish files).</div>
<div>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...</div></div>