You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Speed up the memory allocation and improve the GC performance, especially for dynamic-memory-heavy applications.
NOTE: need go1.18+.
Potential Use cases
A large amount of memory never needs to be released. (global configs, read-only assets like navmesh)
Massive temporary objects with deterministic lifetime. (protobuf objects sent to network)
Highlights
Linear allocator:
Mush faster on memory allocating. An allocation is just a pointer advancement internally.
Can greatly reduce the object marking pressure of GC. Lac is just a few byte arrays internally.
More general. Lac can allocate various types of objects.
Much simpler and faster on reclaiming memories. No need to manually release every object back but just reset the allocation cursor.
Much cheaper. Lac reuse memory chunks among each other via chunk pool.
Memory efficient. Memories are more compact, CPU cache-friendly.
Allows build-in allocated objects to be attached to the Lac allocated objects.
Support concurrency.
Provide protobuf2 style APIs.
Limitations
Never store pointers to build-in allocated objects into Lac allocated objectsdirectly. (There's a debug mode for checking external pointers)
Never store or use pointers to Lac allocated objects after the allocator is released. (In debug mode, the allocator traverses the objects and obfuscate the pointers to make any attempting usage panic)
Map memory can't use Lac and fallback to build-in allocator.
Pros over v1.20 arena
Faster(see benchmark results below).
Support concurrency.
Slice append can utilize Lac as well.
Support debugging mode.
Provide protobuf2 style APIs.
Completely pointer free (no pointer bitmap initializing, no GC marking, etc).