performancepaper VS clj-fast

There is a review of the study at https://github.com/joinr/performancepaper. Basically by using optimization tricks (recur for recursive function call, unchecked math, using Java types, etc.) Tom meets/beats the performance of Java.

I did a contrast with someone's graduate thesis that aimed to analyze clojure vs. java performance and made some weak claims. The rep is here, and it's really the org file. Sort of a worked example of optimizing code.

I often see people knocking on Clojure saying its performance is bad when they are still not familiar with all the core library has to offer and what idiomatic performant Clojure can look like. Take a look here for some examples by joinr

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.