Is there a reason that the clients don’t contain multi-get / multi-set methods? Wondering if it goes against the grain to pull down batches of keys that aren’t in an ordered range given the methods available.
You can make multiple requests in parallel by taking advantage of the fact that the get() methods return futures and that the set() methods just buffer up all writes until transaction commit anyway. Internally, the client is free to combine multiple requests that are headed for the same physical storage server into one network packet.
The only advantage of multi-get or multi-set methods would be potentially saving FFI overhead in some languages by literally reducing the number of function calls to the API.
It would be nice to have a bulk get method at the lower level, because in those language, you can hide that behind the API, but you will still have to allocate multiple Future handles, do multiple interop calls, and wait for multiple callbacks to fire. (I think we talked about this a long time ago).
So the way we can do it today (exposing a single Task/Promise with an array of results that waits for all sub tasks to complete) only saves the allocation of N-1 futures at the upper level, but still incur the cost of N future handles allocations, and 2 x N interop calls (from managed to native and back). This could get down to 1 Task, 1 future handle, and only 2 interop calls (into the C client, and the callback that fires).
This is less of an issue with multi-set, because they don’t need to allocate Future handles nor callbacks. Only cost multiple interop calls.
Cool, was concerned that a ton of sequential gets could be making an ambitious number of network calls.
Hmm from my take on the API perspective, a multi-get seems both much more ergonomic to work with and has the benefit of reducing the number of FFI calls / Futures / callbacks, as KrzysFR mentioned above.