range has a highly optimized implementation (LongRange) for the very common case where all range arguments are longs. However, a common case is: (range (count x)) for some coll x. count returns an int, and thus the optimized range is not used, even though it could be.

A workaround right now is to explicitly coerce:

(range (long (count x)))

Approach

Widen check of arguments to range to see if they are fixed-precision integers per int? (covers: long, int, short, byte in that order), instead of explicit check of instanceof java.lang.Long, increasing the cases where . The LongRange.create() methods take longs so the JVM will upcast to long primitives.

Perf

Timings

I included several versions here as we’ve been changing things in this area so it really matters what you’re comparing against - 1.12.0-alpha1 has lots of range improvements. The changes from alpha1 to master should not have any effect on this test so not sure why seeing 386-433 ms there, may just be sampling error. But importantly, with this patch, LongRange is used which is the optimized path.

Patch: clj-2709-1.patch

Screened by: Alex Miller