i hope we can figure out some way to reduce the size of native-images built with the rewrite-cljc -- iirc, there was a more than 20 MB increase. i wonder if native-image has some kind of tree-shaking or there's some nice way to exclude the cljs stuff for clj native-image builds.
@sogaiu that is interesting. I wonder, do you think anybody would be bothered by a 20mb increase?
yes
why is that?
especially for cmd line programs - if you look around a bit i think you'll find such emissions :)
well, i can give you a concrete situation off the top of my head, but i don't have a good summary atm -- if i think of a good summary i will report π
in the mean time, here is a use case
i use native image binaries for plugins and extensions (for atom and vscode) -- each one being bigger means longer download times
true
perhaps it is premature to be concerned -- it's just something i've been considering for some time and i've noticed other people being concerned about size
but may be it is unwarranted
it could be that native-image will get tree shaking if it doesn't have it already, so may be time will take care of the issue too
I might be macOS upgrade biased... I just updated to macOS 10.15.1 today and if I remember right, it was over 4gb. :simple_smile:
well, it isn't exactly an analogous situation
no but it might have biased my thinking
ok π how often would you say you update macos?
so your concern is currently download times of updates, right?
it is one concern, yes, but i wouldn't say it's the only one
(ya I didnβt mean the bias was sound)
ha ha ha
how many sound biases have you met?
:simple_smile:
just to show i'm not the only odd ball: https://github.com/johnthagen/min-sized-rust https://blog.filippo.io/shrink-your-go-binaries-with-this-one-weird-trick/
for plugins and extensions, it gets worse because to do it well atm, you may need to bundle 3 diff binaries
that's 3 native-image binaries per plugin / extension
so each user has to unfortunately download unwanted bits
if i'm the only one with this concern though, it shouldn't be a burden on anyone else
itβs not a concern I currently share with you, but I can certainly acknowlege it
well, it's a very specific case, so no worries - if it's easy to do something about it, it would be nice :)
FWIW if rewrite-cljc stays close to the implementation of rewrite-clj there should be no difference in binary size: the CLJS branches are ignored during read time.
20mb is twice the size of clj-kondo
sorry, incorrect: clj-kondo packs 15mb right now. the minimal size of a clj binary seems to be around 10mb
thanks for info!