Added khashl and made some changes to the benchmark and dub file.
Khashl is hash table that performs deletions without tombstones allowing it to have a smaller
memory footprint for some sacrifices in speed. It uses fibonacci hashing. Described here.

attractivechaos says this about khashl:

TL;DR: With linear probing, we can delete elements from an open addressing hash table without tombstones.

Deletion speed vs bytes per key

Interestingly, khashl is slower than my older khash.h. This may be caused by a combination of two effects. First, due to the presence of tombstones, khash.h has to double the number of buckets, resulting in fewer collisions. It implicitly trades memory for speed. Second, khashl may need to move multiple elements upon a deletion. Copying buckets can be slow. That said, the new deletion algorithm is only a little slower than khash.h and is faster than many other libraries for this particular task. It might also become faster than khash under a different payload (e.g. large batch of deletions).

Most notably:

In addition, khashl has simpler insertion. It is faster than khash even if no deletions are involved.

Considering the clear advantage in memory, I think the new deletion algorithm without tombstones is overall better than traditional algorithms. It should become the preferred way to implement hash tables.

Time, in msec, for n=500,000 operations benchmarked on WSL (Ryzen 1700); ldc2 -release

There are no retrieval times for the cached version as that benchmark uses integer keys and my khashl template prevents that at compile time as there should be no real benefit for integers.

attractivechaos says this about hash-caching:

When we use long strings as keys, comparing two keys may take significant time. This comparison is often unnecessary. Note that the hash of a string is a good summary of the string. If two strings are different, their hashes are often different. We can cache the hash and only compare two keys when their hashes are equal.