I wonder if the perf of expressions like this are impacted by the IDrop stuff
(take 3 (filter even? (range 100000000)))Because?
Hunch is that this messes with chunking (`even?` is applied to a huge chunk). https://github.com/clojure/clojure/blob/e6fce5a42ba78fadcde00186c0b0c3cd00f45435/src/jvm/clojure/lang/LongRange.java#L120
(count (chunk-first (range 100000000))) is 100000000
In 1.11.1 this would be 32 and laziness would be preserved... while the change seems to make that expression be eager
Range never actually eagerly computed values, so nothing has changed there - it just makes one giant chunk rather than n
I did perf test the range changes in a variety of ways and it is much faster in some cases, like reduce and iteration (a wash in others)
filter is still making a chunk of 32
Ahh, perhaps this isn't the case on Clojure master? If I evaluate (take 3 (filter even? (range 100000000))) in 1.12.1-alpha1, I think I get a huge chunk being evaluated...
Here is a repro... if you evaluate (take 3 (filter (fn [x] (prn x) (even? x)) (range 100))) you will see 100 applications
I’ll take a look
Extracting a bit of the logic from filter this seems relevant: (let [r (range 100)] [(chunked-seq? r) (count (chunk-first r))]) -> [true 100]
Rich and I talked about it today, I'm going to just fall back to making 32-element chunks in range for now, will target that at alpha2
thanks for the question!