This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-04
Channels
- # aleph (24)
- # beginners (60)
- # cider (20)
- # clara (4)
- # cljs-dev (13)
- # cljsrn (4)
- # clojure (66)
- # clojure-italy (32)
- # clojure-nl (4)
- # clojure-serbia (1)
- # clojure-uk (207)
- # clojurescript (115)
- # cursive (3)
- # datomic (36)
- # defnpodcast (1)
- # duct (15)
- # fulcro (14)
- # graphql (8)
- # lein-figwheel (1)
- # leiningen (4)
- # off-topic (140)
- # pedestal (40)
- # portkey (3)
- # reagent (40)
- # remote-jobs (1)
- # ring (11)
- # shadow-cljs (31)
- # spacemacs (6)
- # sql (65)
- # tools-deps (67)
- # yada (1)
Noticed that (seq (eduction ...))
doesn't optimize for when the source to eduction
is a chunked-seq
. Implemented a version Seqable
that does optimize for this case and I've measured a ~1.9x speedup for both clj and cljs for my very few benchmarks.
Gist here with commands to run with clj
and cljs.main
:
https://gist.github.com/petterik/0e0c9bcc4b223c01bbb1442e820ea503
Requires more looking, feel free to file a ticket for clj
Why do we care about eductions over seqs?
They’re most useful for reductions over io-based reducibles
Also seems like we should be aiming to optimize reduce over seqs generally rather than the specific case of eduction
We might not care about eductions over seqs. I just noticed it when benchmarking different ways of doing (first (filter pred coll))
. Calling (first (eduction ..))
is something I do now and then though.
I like to compose code with eductions, but I mostly use them as sources to into
, transduce
or reduce
. So I understand if we don't care.
The code provided in the gist would also work for the 2-arity sequence
call, which may or may not be more interesting.
Hello folks! is ClojureScript core interested in reading the :npm-deps
from package.json
so that users don't have to duplicate their dependencies in two places?