This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-06-20
Channels
- # aws (1)
- # babashka (68)
- # beginners (68)
- # braveandtrue (6)
- # calva (4)
- # cider (10)
- # clj-kondo (26)
- # clojure (76)
- # clojure-dev (18)
- # clojure-europe (1)
- # clojure-norway (25)
- # clojure-spec (8)
- # clojure-sweden (7)
- # clojure-uk (3)
- # clojuredesign-podcast (1)
- # clojurescript (11)
- # conjure (29)
- # cursive (31)
- # datomic (29)
- # emacs (12)
- # fulcro (29)
- # graphql (3)
- # helix (2)
- # hoplon (39)
- # hugsql (4)
- # malli (3)
- # off-topic (62)
- # pedestal (8)
- # re-frame (23)
- # reagent (14)
- # rewrite-clj (10)
- # shadow-cljs (18)
- # spacemacs (3)
- # sql (13)
- # xtdb (32)
I just "fixed" a memory leak by converting (concat ws xs ys zs)
to (concat (concat ws xs) (concat ys zs))
; I can't quite convince myself by staring at the definition of concat
why this would be the case; but is it a known issue/phenomenon?
Without knowing any of the specifics of your problem, https://stuartsierra.com/2015/04/26/clojure-donts-concat came to mind.
yeah, I'm familiar with concat bombs; I don't think that can apply here; the symptom is OOM, not stack overflow, and the reason there's an OOM is the same reason I need to use laziness, I can't just make everything eager like he suggests
(the seqs in question are lazy, of course, and are presumably somehow being overrealized or head-held when they needn't be)
Concat is a function, arguments evaluated, lazy-cat is a macro and does some extra thunkifying
I don't see how it would be a problem that the args are merely evaluated
as long as the whole lazy seqs aren't realized with a held head
I vaguely recall at some point something about concat not being as lazy as it could be, maybe it calls seq on all it's arguments or something (realizing the first element before it is strictly required).
you might be recalling a mapcat ticket I made ages and ages ago