Sure, happy to elaborate. Bifurcan offers potential performance wins a few different ways:
* We can use standard Java equality semantics, bypassing all the overhead of the hash calculations and enhanced numeric equality checks (this can lead to moderate performance gains)
* We can use a mutable data structure as long as it never escapes a local context (this can lead to significant performance gains)
* We can use the extra capabilities the data structures expose, like concatenation, slicing, set operations, etc. (this is too dependent on the use case to really quantify)
it would be easy to have a `map` and `map*` method that expose Clojure and Java equality semantics, respectively, but that puts a big onus on the developer to determine if the latter is safe for their use case. I've been bit by this when I've used j.u.c.ConcurrentHashMap before, so I expect people will suffer similarly weird bugs.
However, I think there's a way to use the mutable data structures. Technically, transient data structures allow arbitrary persistent data structures to be batch updated, but in practice they tend to be empty, and after they're populated they tend to be treated as read-only.
If we're convinced this is common enough, every empty transient data structure could be mutable, and when we make it persistent we could wrap it in a "virtual" collection [1] which allows updates without touching the base collection. This would allow for faster writes, faster reads, and only marginally slower updates if those are required.
This is all predicated on a bunch of assumptions that are hard to validate, but if this describes enough real-world use cases, it could lead to a big, easy performance win. It's even possible to automatically replace the base Clojure collections with these alternatives using something like Sleight [2].
Anyway, that's what I've been mulling over. If anyone has opinions, I'm happy to hear them.
Zach