Roman, Dawid,
Well the idea is half-way there :
https://github.com/vsonnier/hppc/tree/hash-single-arrayIt turns out to be more painful that I thought on the implementation side, I think I'm reaching the limits of Velocity vs. readability of the templates :)
Indeed Roman it consist in patching lots of methods to handle the "special value", quite a pain to write...
As for the iterators, it doesn't seem to have significant impact sor far as my simple benchamark goes. Besides, the steam-like "forEach()" bulk methods
are the canonical way to go, and IMO the iterators are much less useful now except for a pretty enhanced for loop.
Anyway, this simple benchmark
https://github.com/vsonnier/hppc/blob/0.65.x-RT-release/hppcrt-benchmarks/src/main/java/com/carrotsearch/hppcrt/misc/HppcMapSyntheticBench.javaactually shows a quite definite 10% imprevement (at least) from 0.65.x-RT-release to hash-single-array branches. So I'll probably continue this way with all the rest
of maps and sets when I get more more time.
As for Koloboke, I've read before that everything was indeed flatten-out, with K,V packed fields. On the other hand, why would it be "that" more efficient ? After all, when you search / insert ...etc the work is done on keys (or/and allocated flags arrrays) and only when you reach the index to modify then the values need to be read / accessed.
For instance, an extreme case is an unsucessfull search where the value parts never need to be accessed at all.
As a counter-example, on remove() when you pack K,V in both arrays (HPPC shiftConflictingKeys()) it would certainly be faster.
Have a nice WE
Vincent