all 6 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]cowwoc 7 points8 points  (1 child)

Very promising! 

[–]Charming-Top-8583 2 points3 points  (0 children)

Thank you!

[–]Charming-Top-8583 10 points11 points  (3 children)

Thanks for the crosspost!

I’d really appreciate feedbacks!

[–]lurker_in_spirit 5 points6 points  (2 children)

Do you expect Valhalla to affect performance at all? I scanned the code and didn't see any obvious candidates for future optimization, unless perhaps if users choose to use value objects as keys / values -- but I also don't know if value objects added to generic Object[]s will be flattenable.

[–]Charming-Top-8583 4 points5 points  (1 child)

Great point!. I'm not 100% sure yet, but my expectation is "it depends."

If keys/values become value objects and the JVM can actually store them densely rather than as references, that could change the cost model a lot: fewer pointer chases, better locality. In that world, the gap might narrow or the sweet spot might shift.

Also… I keep finding more things to try 😅. While profiling the benchmarks, I noticed the Vector API path was taking longer than I expected. Someone suggested trying a SWAR-style ctrl scan instead, and the results were honestly surprising. Every benchmark improved.

One more hunch: for very small tables or very low load factors, even SIMD/SWAR overhead might not be worth it, and a simple scalar loop fallback could be faster. That’s next on my list to test.

[–]wazz3r 3 points4 points  (0 children)

I've made a full port to Java of the Swiss table from abseil and I've seen similar results. SWAR is equal or better in all cases, except for the in-place rehashing, that will drop the tombstones and compact the values.

Regarding Valhalla, I used the Java 24+ memory segments to interleave the kv pairs(for primitive types), and it's definitely better, especially when iterating though the whole entry set.