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
Whenever a rerun::Collection is owning the data via an allocation, it currently stores it in a std::vector using the default allocator
It would be nice to instead be able to specify arbitrary deallocation for any pointer that is owned by rerun::Collection. Also since rerun::Collection is immutable we shouldn't pay for the capacity field of std::vector either, bloating the size of rerun::Collection unecessarily
Note that this model is also relatively friendly to a small-buffer/inline-buffer optimization:
We can sacrifice one bit on _size to indicate whether an inline buffer is used and then use _data + _dealloc as storage for the inline buffer.
Whenever a
rerun::Collection
is owning the data via an allocation, it currently stores it in astd::vector
using the default allocatorIt would be nice to instead be able to specify arbitrary deallocation for any pointer that is owned by
rerun::Collection
. Also sincererun::Collection
is immutable we shouldn't pay for the capacity field of std::vector either, bloating the size ofrerun::Collection
unecessarilyProposed internal data struct to that end:
Whenever the data is borrowed,
_dealloc
is null.Note that this model is also relatively friendly to a small-buffer/inline-buffer optimization:
We can sacrifice one bit on
_size
to indicate whether an inline buffer is used and then use_data
+_dealloc
as storage for the inline buffer.A working prototype of a different implementation of an inline buffer can be found on this branch https://github.com/rerun-io/rerun/tree/andreas/cpp/rerun-collections-small-collection-optimization
(has no custom deallocator support)
The text was updated successfully, but these errors were encountered: