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.

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?

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!