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

Marco Leise Marco.Leise at gmx.de
Tue Feb 7 21:18:46 PST 2012


Am 08.02.2012, 04:37 Uhr, schrieb Manfred Nowak <svv1999 at hotmail.com>:

> Marco Leise wrote:
>
>> I'm not aware of any caveats, are there any?
>
> The tests only cover a very small fraction of an unknown data
> structure: the allocation phase.
>
> Of course one can want to make a bad design running faster. Especially
> if one need to allocate 0.5 TB main memory and can allocate this in 1
> second instead of 98 seconds.
>
> But neglecting
>
> 1) the time for building a usable data structure of 0.5 TB main memory,
> 2) the time for quering this data structure for some element,
> 3) the time for inserting some element into this data structure,
> 4) the time for deleting some element from this data structure and
> 5) the amortized times of the actions in 3) and 4)
>
> is at least not in accordance with engineering principles.
>
> -manfred

I meant caveats with calloc vs. other allocators. I don't want to discuss  
the design of compression algorithms, that allocate a fixed sized buffer  
in advance. I am porting one of those to D and of the many data structures  
it allocates with calloc, there are some that may not be fully filled when  
the program exits. Yet, the user notices a start-up delay in the D version  
for the memory allocation and initialization as well as an instant jump to  
the maximum memory use. The C++ version starts instantly and maps memory  
pages on demand.
The algorithm relies on some of the buffers being zeroed out, so there is  
really no alternative to calloc.


More information about the Digitalmars-d mailing list