Discussion on Go and D

[Manu]

On 7 April 2012 17:38, Rainer Schuetze <r.sagitario at gmx.de> wrote:

>
>
> On 4/7/2012 12:44 AM, Manu wrote:
>
>> On 7 April 2012 01:08, Rainer Schuetze <r.sagitario at gmx.de
>> <mailto:r.sagitario at gmx.de>> wrote:
>>
>>    I don't think there are many places in the code where these hints
>>    might apply. Are there known ways of hunting down false references?
>>
>>    Still, my main concern are the slow collections that stall the
>>    application when a decent amount of memory is used. Removing false
>>    pointers won't change that, just make it happen a little later.
>>
>>
>> An obvious best-practise is to allocate in fewer-larger blocks. Ie, more
>> compounds and aggregates where possible.
>> I also expect you are doing a lot of string processing. Using D strings
>> directly? I presume you have a stack-string class? Put as many working
>> strings on the stack as possible...
>>
>
> 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.
>
> 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).
>

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.
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).
If D supported allocators, and I had control over the allocation source,
then maybe I'd change my usage patterns...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120407/1e37c739/attachment.html>