Situation
The C++ binding makes heavy use of std::vectorstd::uint8_t for returning keys/values and has several overloads taking const std::vectorstd::uint8_t&. While std::string_view is already used nicely for some inputs, the output paths and many vector-based overloads force allocations + memcpy on every get(), iterator key()/value(), etc.
This is particularly noticeable in high-throughput workloads where keys and values can be moderately large and accessed frequently. Proposed Improvement Introduce std::span (C++20) as the preferred zero-copy view type for binary keys and values.
Benefits:
Near-zero cost to pass/return (just pointer + size)
Eliminates many temporary vector allocations and copies
Better composability with modern C++.
Aligns with the existing C API (which already uses const uint8_t* + size_t)
Keeps the library competitive with other high-performance KV bindings (RocksDB, LevelDB, etc.)
Concrete Suggestions
Input methods (add span overloads)
void put(ColumnFamily& cf, std::span key,
std::span value, std::time_t ttl = -1);
// Similarly for del, singleDelete, seek, compactRange, etc.
Lifetime Notes (important)
Returned spans are non-owning. They remain valid only as long as the underlying iterator/transaction/column-family data is stable. This is standard behavior for view types — document it clearly.
Additional Considerations
Minimum C++ standard → bump to C++20 (already using C++17 features; this is a reasonable step)
Motivation / Use Case
In performance-critical applications, avoiding even modest copying per operation yields measurable gains in throughput and latency.
Situation
The C++ binding makes heavy use of std::vectorstd::uint8_t for returning keys/values and has several overloads taking const std::vectorstd::uint8_t&. While std::string_view is already used nicely for some inputs, the output paths and many vector-based overloads force allocations + memcpy on every get(), iterator key()/value(), etc.
This is particularly noticeable in high-throughput workloads where keys and values can be moderately large and accessed frequently. Proposed Improvement Introduce std::span (C++20) as the preferred zero-copy view type for binary keys and values.
Benefits:
Near-zero cost to pass/return (just pointer + size)
Eliminates many temporary vector allocations and copies
Better composability with modern C++.
Aligns with the existing C API (which already uses const uint8_t* + size_t)
Keeps the library competitive with other high-performance KV bindings (RocksDB, LevelDB, etc.)
Concrete Suggestions
Input methods (add span overloads)
void put(ColumnFamily& cf, std::span key,
std::span value, std::time_t ttl = -1);
// Similarly for del, singleDelete, seek, compactRange, etc.
Lifetime Notes (important)
Returned spans are non-owning. They remain valid only as long as the underlying iterator/transaction/column-family data is stable. This is standard behavior for view types — document it clearly.
Additional Considerations
Minimum C++ standard → bump to C++20 (already using C++17 features; this is a reasonable step)
Motivation / Use Case
In performance-critical applications, avoiding even modest copying per operation yields measurable gains in throughput and latency.