Optimize CollectionSpec checker

[nilern]

• Replace a doseq with reduce on JVM
• Accumulate into a JS array on cljs instead of a persistent vector in an atom

The latter could improve #356 substantially; in the Malli seqex impl I had a similar situation with a persistent set in an atom on cljs and it was just unacceptably slow.

[w01fe]

Why is this expected to be faster? The List can't be used safely concurrently so I would be surprised if you could do better than the doseq. Have you profiled and seen a speedup?

[nilern]

reduce (and run!) is faster and more memory efficient because as an internal iterator it can be fully specialized to the collection and usually does not need to allocate at all. I have profiled it sometime but by now it is just a habit like using (into [] (map ...) x) instead of (into [] (map ... x)). Since reduce works on all seqs really the only reason to ever use doseq is if :when/:while/:let is super useful.

[w01fe]

The weird thing about reduce here is that it's threading through an extra argument that you don't care about because you're mutating the argument anyway. I think it makes the code slightly less clear and I would be a bit surprised if there was a performance benefit, but I'd be happy to believe it if there were accompanying measurements.

[frenchy64]

The weird thing about reduce here is that it's threading through an extra argument that you don't care about because you're mutating the argument anyway.

Might be worth comparing to (reduce #(.add res (c %2))) nil x).

[frenchy64]

Oh, it would probably beat the current code handily since I don't see a type hint on the inner res.

EDIT: I've added a reflection check to the master build.
EDIT2: Of course I missed the doto propagating the type hint, nevermind.

[w01fe]

I believe that something mutable could be faster here, but I'm again unsure about the use of reduce. Can you share profiling results?

[nilern]

into uses reduce too! Here it is more important that the data structure is mutable. I'll do some profiling later.

[w01fe]

I'm not super familiar with cljs, can you explain the change here please?

[nilern]

Now that l is a JS array it just uses Array#some.

[w01fe]

Thanks. Is that expected to be appreciably faster?

[w01fe]

Thanks for the PR! Certainly happy to accept optimizations but always prefer if they come with measurements. And would like to learn more about the choice of reduce over doseq.

[nilern]

I want to do some benchmarks but for now I am out of time.

[w01fe]

Thanks! I just want to make sure we are striking the right balance between performance and clarity, i.e. only making optimizations that make a measurable difference. My intuition is admittedly stale here, so I'm happy to take these with measurements, or happy if another maintainer wants to take them without.

[nilern]

I don't think this adds much complexity; it is just using JS arrays just like it was already using ArrayList on the JVM.

While I am fairly confident it will also be faster it would be silly to optimize without benchmarking.