ham-fisted VS clj-fast

3 - Similar to 2, the savings of mutably building the collection have to outweigh the cost of persisting it. Or if you are using the transient as a mutable container (e.g. held by an item) for limited random access and writes (as opposed to say a mutable arraylist or hashmap or hashset), performance should still be substantially better for writes over the persistent counterparts. The most gains come from building up large collections, using transients to mutably collect values and then persist at the end. Similar idea (but more general) in ham-fisted.

I have taken the time in between caring for my young son to write a new library that provides higher performance datastructures and algorithms for Clojure.

IIRC clojure.core/merge is another needlessly slow implementation that gets used a lot. If you are leveraging that on hot paths you will probably see some benefit in writing your own variant or copying one (or adding a dep) from a lib that is faster. There are some explorations of these ideas in clj-fast with some early results and trends and plenty of interesting discussions in the issues.

Noticed that code compiled in a defn as opposed to raw evaluation of the body at the repl produces different bytecode (and impacts inlining / jit) in some cases https://github.com/bsless/clj-fast/issues/16 . Kind of a cousin to the original issue you raised.

Some interesting exploration in the clj-fast library and discussions in the issues there.

The only other weird performance regression with array looping code is if you test it at the repl vs inside a defined function that's called. Different bytecode emitted in each case for some reason, with the function wrapper version being substantially faster.