Am 08.02.2012, 04:37 Uhr, schrieb Manfred Nowak <svv1...@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.
