This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-02
Channels
- # beginners (72)
- # boot (68)
- # cider (51)
- # clara (20)
- # cljs-dev (44)
- # cljsrn (7)
- # clojure (168)
- # clojure-brasil (1)
- # clojure-dev (48)
- # clojure-greece (2)
- # clojure-nl (29)
- # clojure-russia (4)
- # clojure-spec (19)
- # clojure-uk (28)
- # clojurescript (2)
- # cursive (9)
- # datascript (1)
- # datomic (105)
- # dirac (1)
- # docker (2)
- # duct (11)
- # emacs (19)
- # events (1)
- # figwheel (1)
- # fulcro (23)
- # garden (4)
- # graphql (5)
- # hoplon (46)
- # jobs (5)
- # juxt (13)
- # leiningen (6)
- # lumo (12)
- # off-topic (29)
- # parinfer (5)
- # re-frame (7)
- # reagent (6)
- # ring (2)
- # sql (5)
- # yada (6)
Any thoughts about https://dev.clojure.org/jira/browse/CLJ-2319 ?
I haven’t had time to look at it in depth yet. Any change in the heart of function application is going to require very serious evaluation.
It’s also unclear to me what the practical performance impact is in a real world app
I believe it’s a lot faster but if it’s a case that rarely occurs, then ...
Yeah that would entirely depend on what the real world app does. If there are apps/algorithms that use apply
a lot then it could be quite significant for those.
walking a seq multiple times does not add any additional garbage so that does not make sense to me
I think every next
call generates a new object that's just discarded right away. That's what the RT.boundedCount
does.
effectively 0% of people use send and send-off
Not necessarily a big deal, but noticed that
(let [n 10] (first (sequence (partition-all n)) (range))
realizes (* n (inc 32))
items. Possibly more than you'd expect?
It looks like you have two arguments to first? Am I cross eyed?
apologies, mismatched a parent during last edit (let [n 10] (first (sequence (partition-all n) (range))))
how do you come to that conclusion wrt realization? certainly as a sequence using transducers (which are a pull model) I’d expect the first partition to be fully realized. And the long range produces 32 element chunks at a time (although it doesn’t actually “realize” the values in the chunk at all)
I printed them: (let [n 10] (first (sequence (comp (map #(do (print % ",") %)) (partition-all n)) (range))))
I think it might be more the chunkIteratorSeq
because it does the same with non-chunked seqs
(defn unchunked-sequence [xform coll]
(->> coll
(clojure.lang.RT/iter)
(clojure.lang.TransformerIterator/create xform)
(clojure.lang.IteratorSeq/create)))
the chunking of sequence
vs the chunking of lazy sequences is quite different in that sequence
will chunk over the output seq while lazy sequence ops will chunk over the input seq
I honestly don’t think that the chunking in sequence
should be there, because of exactly this
it’s super easy to consume a massive number of elements from the input coll by using sequence xform
if instead chunking was implemented as a transducer transformer (I believe a while ago @cgrand demostrated that this is possible), we’d be able to control both chunk size and where in the pipeline the chunking is applied, decomplecting chunking from laziness
the complecting is even worse for sequence xform
than it is for lazy-seq ops, as for the latter it is possible to opt out of chunking after the fact by writing the usual unchunk
function , wihle for sequence xform
the only way to opt out of chunking is not to use sequence xform
and roll your own like mine above
unchunk for lazy seqs is usually defined as :
(defn unchunk [s]
(when (seq s)
(lazy-seq
(cons (first s)
(unchunk (next s))))))
ah, I thought you were saying that (first (unchunk (partition-all 10 (range))))
would consumes only 10 items
while it’s not possible to write a (sequence (comp xform unchunk) x)
or (sequence xform (unchunk coll))
IMO chunking should be a property of the xform, not coupled to the xform context is what I’m saying
becasue I don’t want people to roll their own xform contexts when a transducer would do
chunked-aware fns are not that documented in general