public inbox for keks@lists.stargrave.org
Atom feed

From: Sergey Matveev <stargrave@stargrave•org>
To: keks@lists.stargrave.org
Subject: Memory pooled items storage
Date: Sun, 28 Jun 2026 21:37:30 +0300	[thread overview]
Message-ID: <akFp6swdKHlHOkIO@stargrave.org> (raw)

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]

Greetings!

Latest commits bring a memory-pool based KEKSItems storage. Previously
it used a continuous slice of bytes which is fully relocated when grown.
Current memory-pool storage does not reallocate anything, but allocates
new chunks, linking them together. As in the previous implementation,
you may specify those chunks size if you know your decoded structures
sizes in advance. That gives a huge boost of decoding performance.

As a side effect, now you can safely use pointers to the decoded
KEKSItem and KEKSAtom, because of no reallocation involved.
In practice, that may considerably simplify the code.

Ability to use fixed buffers and no heap-based allocators (malloc()) is
also stayed. You can specify a callback for memory allocator, which can
behave any way you wish. But there is a helper function for a fixed
buffer ready to be used out of box:

    struct KEKSMemPoolAllocatorFixedBuf fixedBufAllocatorState = {0};
    items.allocator = KEKSMemPoolAllocatorFixedBufNew(
        &fixedBufAllocatorState, fixedBuf, fixedBufLen);
    err = KEKSItemsInit(&items, chunkLen);

KEKSMemPool subsystem is completely free of anything related to KEKS and
can be used independently, to store any kind of objects with predefined
alignment requirements.

-- 
 * Origin: Stargrave's homepage http://www.stargrave.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

                 reply	other threads:[~2026-06-28 18:39 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed