Permalink
Reply
On Friday, 13 October 2023 at 11:32:29 UTC, Imperatorn wrote:
>Hello there.
I'm wondering if anyone would be opposed to us/me making associative array having resize/reserve public?
Currently there exists private members in druntime etc for this but they are not exposed.
Basically I would like to be able to reserve n buckets before populating.
For reference, see std::unordered_map, which is kvp, which has rehashing etc:
template<typename _Key, typename _Tp,
typename _Hash = hash<_Key>,
typename _Pred = equal_to<_Key>,
typename _Alloc = allocator<std::pair<const _Key, _Tp>>>
class unordered_map
{
typedef __umap_hashtable<_Key, _Tp, _Hash, _Pred, _Alloc> _Hashtable;
_Hashtable _M_h;
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/unordered_map.h
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/hashtable.h
In my opinion C++ / STL containers in std are pretty meh, and one probably should not be guided by them. unordered_map design and requirements in particular are bad.
I like reserve, but I would say: show real world example, and benchmark (not microbenchmark, but actual app), where reserve helped (i.e. it is also easy to use reserve and actually make code / memory / cpu usage worse). Then maybe.
For example, reserve on tree based associative array, does not really make sense.
If you need reserve, maybe you need to not relay on any specific AA implementation provided by D runtime by default, but rather use library or own solution, that you control over time. Otherwise, change in a compiler or runtime, could obliterate any performance improvements you had before. (i.e. what if it was critical to performance, and at next dmd version, reserve started just being ignored, then you are in a big trouble).