This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-04
Channels
- # adventofcode (154)
- # announcements (1)
- # babashka (8)
- # beginners (28)
- # bristol-clojurians (3)
- # calva (131)
- # cider (43)
- # clj-kondo (14)
- # clojure (135)
- # clojure-europe (1)
- # clojure-italy (7)
- # clojure-madison (1)
- # clojure-nl (6)
- # clojure-spec (8)
- # clojure-uk (90)
- # clojurescript (47)
- # core-async (9)
- # cryogen (4)
- # cursive (12)
- # datomic (9)
- # emacs (7)
- # fulcro (5)
- # graalvm (56)
- # joker (4)
- # juxt (1)
- # leiningen (6)
- # off-topic (62)
- # pathom (4)
- # pedestal (2)
- # reagent (2)
- # reitit (5)
- # ring (2)
- # schema (4)
- # shadow-cljs (133)
- # sql (38)
- # tools-deps (10)
- # vim (28)
Has anyone done any profiling on which part of core.async contributes most to the load time?
It's not prohibitive, but it was enough that I refactored some code to use future
instead of thread
to avoid it.
The delay happens at require time. Just adding the (:require...) clause to the ns declaration adds about a second of time.
I'm sure there's plenty of stuff in async that makes that delay reasonable (if it's needed). I was just wondering if anyone had looked into what causes the delay.
It’s the macro stuff, has nothing to do with the threads
Ghadi actually has a speculative refactor that loads the go loop stuff on demand, avoiding the delay if you’re not using go’s but I’m not sure if that’s common enough to be worth the trouble