<div class="gmail_quote">On 7 April 2012 17:38, Rainer Schuetze <span dir="ltr"><<a href="mailto:r.sagitario@gmx.de">r.sagitario@gmx.de</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"><br>
<br>
On 4/7/2012 12:44 AM, Manu wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 7 April 2012 01:08, Rainer Schuetze <<a href="mailto:r.sagitario@gmx.de" target="_blank">r.sagitario@gmx.de</a><br></div><div class="im">
<mailto:<a href="mailto:r.sagitario@gmx.de" target="_blank">r.sagitario@gmx.de</a>>> wrote:<br>
<br>
    I don't think there are many places in the code where these hints<br>
    might apply. Are there known ways of hunting down false references?<br>
<br>
    Still, my main concern are the slow collections that stall the<br>
    application when a decent amount of memory is used. Removing false<br>
    pointers won't change that, just make it happen a little later.<br>
<br>
<br></div><div class="im">
An obvious best-practise is to allocate in fewer-larger blocks. Ie, more<br>
compounds and aggregates where possible.<br>
I also expect you are doing a lot of string processing. Using D strings<br>
directly? I presume you have a stack-string class? Put as many working<br>
strings on the stack as possible...<br>
</div></blockquote>
<br>
There isn't a lot of string processing involved: tokens take a slice on the original text, and nodes of the AST seldomly save more than the identifier which just the same slice. So the full text always remains in memory, but this is only small part of the actual footprint, the AST is a lot bigger.<br>

<br>
The nodes have child and parent references, so you keep the whole AST once there is a false pointer to any node. I could try breaking up this dependencies when I think the AST is no longer used, but that brings me back to manual memory management and thread synchronization (parsing uses std.parallelism).<br>

</blockquote></div><br><div>Hmm. Well I have to say, thus far, I personally have basically no confidence in the D GC, and tend to avoid it where possible. I only use it for trivial/transient allocations, and for convenience where it makes sense.</div>
<div>In my work so far, I still tend to perform manual memory management for all major resources (this stems largely from the fact that in my line of work, allocations need to be predictable, and often pooled).</div><div>
If D supported allocators, and I had control over the allocation source, then maybe I'd change my usage patterns...</div>