The below benchmarks come from writing 100 int-to-int mappings to
a new hashtable then reading them back, repeated 10_000 times.
The built-in AA doesn't deallocate memory when it falls out of
scope but the other maps do. Benchmark code in next post.
== Speed Ranking using LDC2 (optimized) ==
21 msecs vibe.utils.hashmap
37 msecs memutils.hashmap
57 msecs built-in AA
102 msecs jive.map
185 msecs containers.hashmap w/GCAllocator
240 msecs containers.hashmap w/Mallocator
== Speed Ranking using DMD (optimized) ==
55 msecs memutils.hashmap
64 msecs vibe.utils.hashmap
80 msecs built-in AA
131 msecs jive.map
315 msecs containers.hashmap w/GCAllocator
361 msecs containers.hashmap w/Mallocator
** What if the array size is smaller or larger? The ordering
didn't change so I won't post the results. **
** What if we reuse the hashtable? **
== Speed Ranking using LDC2 (optimized) ==
10.45 msecs vibe.utils.hashmap
11.85 msecs memutils.hashmap
12.61 msecs containers.hashmap w/GCAllocator
12.91 msecs containers.hashmap w/Mallocator
14.30 msecs built-in AA
19.21 msecs jive.map
== Speed Ranking using DMD (optimized) ==
18.05 msecs memutils.hashmap
21.03 msecs jive.map
24.99 msecs built-in AA
25.22 msecs containers.hashmap w/Mallocator
25.75 msecs containers.hashmap w/GCAllocator
29.93 msecs vibe.utils.hashmap
== Not benchmarked ==
stdx.collections.hashtable (dlang-stdx/collections): compilation
error
kontainer.orderedAssocArray (alphaKAI/kontainer): doesn't accept
int keys
tanya.container.hashtable (caraus-ecms/tanya): either has a bug
or is very slow
