nio_uring
nio_uring copied to clipboard
bbeaupain
Alternatives for primitive maps
Thanks for the amazing work in this project. The narrow focus and attention to detail is much appreciated.
I was curious to understand the decision to take the dependency on Colt for primitive maps, given alternatives like Eclipse Collection's LongObjectMap or the open addressing maps from Agrona.
Do you have any interest in dropping the Colt dependency in favor of a smaller/slimmer dep focused only on the primitive collection?
Absolutely open to dropping this dependency in favor of something else. The only reason I went with Colt was because it had lower overhead than java.util.HashMap in benchmarks. Admittedly though, I didn't do much research into more alternatives. I'll dig into some of the maps you pointed out, thank you!
How about support injecting in a MapFactory to a FileFactory class? The default could be JDK-native maps and then allow users to use any map type they want at runtime by adding their dependency and wiring in a MapFactory?
It's an interesting idea @mattrpav (I'd imagine the arg could be a Supplier), but the FileFactory would have to be generic over the Supplier's Map type. Many of the primitive map implementations don't implement the java.util.Map interface (because the signatures are primitive types, not object types). I suppose the contract could be widened later when all the Valhalla changes land in the JDK.
Definitely some interesting suggestions going on here!
A factory approach would be flexible for sure, but it does lead me to wonder however, if it would be worth the additional complexity. I would definitely be more inclined if additional functionality could be swapped in/out with this, but at this point in time it's really just an optimization problem that typically will have one best (or at least good enough) approach that achieves good balance between runtime performance and package weight.
Switched to eclipse collections: https://github.com/bbeaupain/nio_uring/pull/18