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