This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-30
Channels
- # announcements (41)
- # aws (2)
- # aws-lambda (1)
- # babashka (51)
- # babashka-sci-dev (15)
- # beginners (56)
- # calva (15)
- # cider (8)
- # clojars (6)
- # clojure (107)
- # clojure-dev (6)
- # clojure-europe (33)
- # clojure-france (3)
- # clojure-nl (4)
- # clojure-sg (2)
- # clojure-uk (8)
- # clojurescript (16)
- # cursive (11)
- # data-oriented-programming (1)
- # datomic (4)
- # events (11)
- # fulcro (15)
- # graphql (6)
- # helix (17)
- # holy-lambda (1)
- # improve-getting-started (14)
- # integrant (39)
- # jobs (14)
- # lsp (36)
- # malli (3)
- # nrepl (8)
- # off-topic (26)
- # other-languages (1)
- # polylith (21)
- # portal (7)
- # practicalli (17)
- # re-frame (7)
- # react (4)
- # reitit (1)
- # remote-jobs (6)
- # sci (1)
- # shadow-cljs (45)
- # spacemacs (12)
- # tools-deps (5)
- # xtdb (26)
I just realized the structural equality semantics could be sped up significantly if equiv()
is implemented for the non-abstract types. There are happier paths the code could take:
• When comparing vectors, nth
is called for every element (worst case), but nth
always calls arrayFor
which isn't reused
• When comparing maps, the map casts itself to a sequence first
These cases can go through reduce
and reduce-kv
respectively and give dramatically different results.
Should I open a ask.clojure issue for it?
https://ask.clojure.org/index.php/11124/persistent-collections-implement-equiv-more-efficiently
@UK0810AQ2 I would check the size of counted collections to completely avoid iteration over them if size is different.
@U0HJNJWJH that's a common feature of all implementations of equiv I skipped over, rationale detailed in the discussion