[c++] Provide different modes of handling memory when converting to Arrow objects #4334
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issue and/or context:
#4299 #4311 provide memory optimization to reduce overall memory copies and overallocation of memory but introduced a necessary memory copy in the read path.
Changes:
This PR introduces the option to optimize memory management for read operations based on two modes
PERFORMANCEandEFFICIENCYPERFORMANCE: The allocated buffers used for reading from TileDB are passed to the Arrow arrays and a new set of buffers is allocated for subsequent reads. This mode preserves the current behavior but can be wasteful on memoryEFFICIENCY: A new set of buffers is allocated to be used by the Arrow array. These buffers are appropriately sized to exactly match the data read from TileDB. A memory copy operation is then performed for each buffer. If the read buffers are completely filled then the memory copy is avoided and the buffers are used directly by Arrow and a new buffers is allocated for TileDB reads.Notes for Reviewer:
There are currently two almost equivalent implementations for
ColumnBufferto be used during reads. Thestd::vectorone uses a custom allocator to avoid initializing the memory during resize. Under Debug the custom allocator is not being optimized by the compiler and the resulting code is orders of magnitude slower (this can be somewhat mitigated by using-Oginstead of-O0optimization). In Release the compiler generated almost identical code with the array based implementation.