How to save RAM in D programs (on zero initialized buffers)

Marco Leise Marco.Leise at gmx.de
Thu Feb 9 01:36:56 PST 2012


Am 09.02.2012, 03:56 Uhr, schrieb Manfred Nowak <svv1999 at hotmail.com>:

> Marco Leise wrote:
>
>> That sounds a bit vague.
>
> Andrei has written a paper on allocation:
>   http://erdani.com/publications/cuj-2005-12.pdf
>
> -manfred

Oh ok, that's farther than I ever digged into memory management. My  
current problem with the compression utility has been solved at a small  
scale with a manual memory management 'ZeroInitializedAndAlignedBuffer'  
struct that uses calloc - right in the spirit of the original source code.  
The startup time was reduced by ~0.7 seconds and is now relaitvely close  
to the original as well, at least there is no longer that perceived delay.  
Techniques like calloc make it possible to use the algorithm in other  
places like batch processing, compressed FUSE file systems on Linux or  
libraries, where the new instances may be spawned in quick succession.

All technical details aside, I would wish for some solution to "I spawn a  
new instance of some huge complex data structure, but I probably wont need  
all of it, so use calloc". I don't know what the situation with other D  
programs is, but would be interested in some larger scale experiments with  
calloc and app startup time. It may be worse in some cases, but what if it  
improved the general situation - without writing a memory management  
library? I don't know the GC internals enough to tell if calloc is already  
used somewhere (in place of malloc and memset).


More information about the Digitalmars-d mailing list