This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-02-12
Channels
- # babashka (22)
- # beginners (112)
- # calva (7)
- # cider (2)
- # clj-kondo (43)
- # cljdoc (25)
- # cljsrn (30)
- # clojars (16)
- # clojure (73)
- # clojure-australia (2)
- # clojure-bay-area (8)
- # clojure-europe (16)
- # clojure-finland (1)
- # clojure-italy (2)
- # clojure-nl (7)
- # clojure-uk (9)
- # clojurescript (28)
- # clojureverse-ops (2)
- # conjure (2)
- # css (22)
- # cursive (28)
- # datomic (9)
- # depstar (28)
- # emacs (6)
- # fulcro (39)
- # graalvm (61)
- # honeysql (38)
- # instaparse (3)
- # jobs (1)
- # kaocha (3)
- # malli (7)
- # pathom (83)
- # sql (3)
- # tools-deps (18)
- # vim (2)
- # xtdb (15)
New GraalVM release: https://www.graalvm.org/release-notes/21_0/#21002, with just bug fixes on the updater tool
Did anyone try this https://upx.github.io/ to decrease the native image size?
yes. it works, but it will inccrease startup somewhat (like it adds 100-200ms or so)
which for babashka / clj-kondo I did not find acceptable, but for clojure-lsp I can see that being acceptable since it's a long running server
I see, do you know why it increase the startup? it's kind of curious :thinking_face:
nice, I'll give a try and try some benchmarks to see if it works nice for clojure-lsp
most people have indicated in the babashka survey 2020/11 that binary size wasn't a huge priority for them
I think what matters most is network size, so if the release file is a zip, you save network bandwidth, but on the machine the unzipped size doesn't matter much
I have sometimes found that having a runtime require or resolve in your code can bloat the binary with 30 mb or so. so I usually hunt that spot down and get rid of it using alter-var-root or whatnot
oh, good to know! I think the only require clojure-lsp has at runtime is via dynaload
but only require nrepl if in a debug profile (not graalvm)
this is why I've made a graalvm variation of this here: https://github.com/borkdude/dynaload
by setting the java property borkdude.dynaload.aot=true
when compiling natively, it will yield smaller binaries
to be sure, put a (println (System/getProperty "borkdude.dynaload.aot"))
at the top level in your code
just tried adding to the :jvm-opts of my :native-image profile that is used during the uberjar:
:jvm-opts ["-Xmx2g"
"-server"
"-Dclojure.compiler.direct-linking=true"
"-Dclojure.spec.skip-macros=true"
"-Dborkdude.dynaload.aot=true"]
so I changed the uberjar task to this:
:uberjar {:aot :all
:jvm-opts ["-Dclojure.compiler.direct-linking=true"
"-Dclojure.spec.skip-macros=true"
"-Dborkdude.dynaload.aot=true"]}
But even when lein uberjar && java -jar target/clojure-lsp-*-standalone.jar
I still get the nil print for all those variablesSo, after a lot of debugging I started to wonder if babashka is really being compiled with those flags, I added this to babashka main first line:
(println (System/getProperty "borkdude.dynaload.aot"))
(println (System/getProperty "clojure.compiler.direct-linking"))
(println (System/getProperty "clojure.spec.skip-macros"))
Then I run:
script/uberjar
script/compile
and when running ./bb
I get:So you should put them on the top level and watch if they are printed during compilation
So, the clojure.compiler.direct-linking
was correctly configured, it was just missing the dynaload config that i"ll add now 🙂
This seems to compile a producer and consumer with clojure: https://github.com/dainiusjocas/clojure-kafka-graalvm-native-image Maybe can help you
There is also this: https://github.com/tzzh/pod-tzzh-kafka A pod which you can use from babashka scripts.