public inbox for keks@lists.stargrave.org
Atom feed
* Memory pooled items storage
@ 2026-06-28 18:37 Sergey Matveev
0 siblings, 0 replies; only message in thread
From: Sergey Matveev @ 2026-06-28 18:37 UTC (permalink / raw)
To: keks
[-- 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 --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-06-28 18:39 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-06-28 18:37 Memory pooled items storage Sergey Matveev