Container.Chunk

Chunk allocator (non GC)

Can save approximately 30% memory for small elements (tested with integer elements and a chunk size of 1000), and is at least twice as fast at adding elements when compared to the default allocator (approximately 50x faster with LinkedList)

Note that, due to GC behaviour, you should not configure a custom allocator for containers holding anything managed by the GC. For example, you cannot use a MallocAllocator to manage a container of classes or strings where those were allocated by the GC. Once something is owned by a GC then it's lifetime must be managed by GC-managed entities (otherwise the GC may think there are no live references and prematurely collect container contents).

You can explicity manage the collection of keys and values yourself by providing a reaper delegate. For example, if you use a MallocAllocator to manage key/value pairs which are themselves allocated via malloc, then you should also provide a reaper delegate to collect those as required.

The primary benefit of this allocator is to avoid the GC scanning the date-structures involved. Use ChunkGC where that option is unwarranted, or if you have GC-managed data instead

struct Container

struct Chunk (

) {

T* allocate();

T*[] allocate(size_t count);

void collect(T*[] t);

void collect(T* p);

bool collect(bool all);

void config(size_t chunks, int allocate);

}

Members

Functions

allocate T* allocate(): allocate a T-sized memory chunk
allocate T*[] allocate(size_t count): allocate an array of T* sized memory chunks
collect void collect(T*[] t): Invoked when a specific T*[] is discarded
collect void collect(T* p): Invoked when a specific T is discarded
collect bool collect(bool all): Invoked when clear/reset is called on the host. This is a shortcut to clear everything allocated.
config void config(size_t chunks, int allocate): set the chunk size and prepopulate with nodes

Container.Chunk

Members

Functions

Meta

Source