This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-20
Channels
- # aleph (12)
- # announcements (7)
- # aws (6)
- # babashka (36)
- # beginners (161)
- # boot (1)
- # calva (6)
- # cider (21)
- # clj-kondo (13)
- # cljs-dev (28)
- # cljsrn (1)
- # clojars (3)
- # clojure (13)
- # clojure-colombia (1)
- # clojure-europe (10)
- # clojure-spec (12)
- # clojure-uk (47)
- # clojuredesign-podcast (2)
- # clojurescript (67)
- # datascript (8)
- # datomic (21)
- # duct (3)
- # emacs (6)
- # events (1)
- # fulcro (6)
- # graalvm (98)
- # jobs (1)
- # kaocha (18)
- # luminus (1)
- # malli (7)
- # off-topic (56)
- # pathom (5)
- # re-frame (18)
- # reagent (3)
- # reitit (9)
- # remote-jobs (3)
- # rewrite-clj (10)
- # ring (1)
- # shadow-cljs (155)
- # spacemacs (2)
- # sql (5)
- # tools-deps (27)
- # vim (86)
- # xtdb (2)
I had a chance to look a bit deeper at what causes clojure.test
to bloat GraalVM native-image RAM usage. It discovers what tests it will run at runtime using functions such as ns-interns
. When I brought an ns-interns
call into my hello world GraalVM app, it exhibited similar bloat and exe size to my hello world test GraalVM app. To avoid the bloat, I'm thinking a cljs test approach could work. If I understand, out of necessity, cljs builds up tests to run at compile time via macros.
By the way (might be old news to the more experienced, but), I find GraalVM's native-image
expert option -H:+PrintAnalysisCallTree
useful in figuring out what it being brought into a native image.
@lee Oh that's interessting. I haven't used that option before. Maybe something for clj-graal-docs?