clojure-dev 2022-12-14

I wonder if the perf of expressions like this are impacted by the IDrop stuff

(take 3 (filter even? (range 100000000)))

Alex Miller (Clojure team) 2022-12-14T03:50:59.466689Z

Because?

(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

Alex Miller (Clojure team) 2022-12-14T13:11:12.676299Z

Range never actually eagerly computed values, so nothing has changed there - it just makes one giant chunk rather than n

Alex Miller (Clojure team) 2022-12-14T13:12:36.934039Z

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)

Alex Miller (Clojure team) 2022-12-14T13:14:27.609529Z

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

Alex Miller (Clojure team) 2022-12-14T13:53:14.637009Z

I’ll take a look

👍 1

Extracting a bit of the logic from filter this seems relevant: (let [r (range 100)] [(chunked-seq? r) (count (chunk-first r))]) -> [true 100]

💯 1
Alex Miller (Clojure team) 2022-12-14T20:52:09.271969Z

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

😮 2
Alex Miller (Clojure team) 2022-12-14T20:52:15.092179Z

thanks for the question!

👍 1
➕ 1