https://issues.dlang.org/show_bug.cgi?id=2504: reserve for associative arrays

[Shachar Shemesh via Digitalmars-d]

On 02/11/16 05:36, Andrei Alexandrescu wrote:
> Cons:
>
> * Built-in hashtables are a convenience facility more than a
> high-performance one, so providing an efficiency-oriented primitive
> seems a bit odd.
>

I think that, in itself, is a mistake. A language that thinks of itself 
as a system programming language cannot, I think, provide hash functions 
that are designed to be "convenience over performance".

I also think the basic approach is flawed. If we're talking about GC 
backs storage for everything, then "reserve" should not attempt to 
pre-allocate memory to the values. Instead, "reserve" should set the 
hash table size.

In other words, if I call "hash.reserve(10_000)", and then insert 10,000 
elements, I'm less concerned with allocations for the values (especially 
if it's defined to be GC controlled and non-contiguous anyways), and 
more concerned about it not rehashing while I insert due to the table 
getting full.

To me, "reserve" is more about preventing copying data around due to the 
data structure being surprised from the number of elements it needs to 
handle than it is about preventing any allocations during the insert. If 
the values are stored in a linked list, and do not need to be copied no 
matter what, then reserve need not do anything about them at all.

Lastly, if "reserve" doesn't do anything under a certain implementation 
because it makes no sense, that is not a problem as far as I'm 
concerned. If an implementation does not gain performance from calling 
"reserve", that is not a reason not to have the function. It can just be 
a no-op, and I'm fine with calling it an "implementation detail". As 
such, I don't think it is a problem for future changes to the underlying 
structure.

Shachar