Hacker News Reader

Comment by stefanha | Hacker News Reader

> The full build of all Git functionality in Rust is currently around 27M, but since a large part of it is a library, it could clearly be easily split up into domains of functionality - subcrates that do specific things.

I downloaded v0.3.99 for Linux x86_64 and stripped the binary. It ends up at 31 MB. The .text section is 25 MB.

I'm surprised by the large size. On my system /usr/bin/git is 4.7 MB, although git is split up into multiple programs. I'm not comparing apples to apples, but this is weird.

If anyone digs into the binary size, please share what you find.

View on HN

I would also be interested.

I haven't dug into this at all yet, nor have I tried to optimize the size (or really, anything else).

However, the library part will be less than half of this - a lot of code is spent on the CLI specific stuff and would not be part of the library, which is mostly what I care about for the purposes of this project. The CLI part is just to try to prove the point that it actually does what Git does. The library part is what might be useful in that nothing else exists that does all of the things that it does (provide a reentrant linkable library that is feature complete with Git).

Looking at just the `grit` executable, 58 of the top 200 largest file->resulting code sources are from clap-rs' derive functionality i.e. it's the command-line parsing. The #1 largest is, surprisingly, merge_trees[1] which comes in at 183kiB final binary size. There isn't so much code in that file that it seems reasonable, so it's potentially one of the derives in use (Debug being a common culprit for bloat) that's blowing it out. After those outliers it starts to level out quickly.

Splitting it by crate: `grit` is 13.6MiB, `grit_lib` is 4.8MiB and then it's `std`, `rustls` and `regex_automata` that are the next largest. So as pure library you could hopefully shave off quite a bit of that 25MiB.

[1] https://github.com/gitbutlerapp/grit/blob/main/grit-lib/src/...

Nice, I haven't dug into this yet. If we can get this usable, it would be pretty cool to have a small lib or a series of much smaller, directed libs that can be used by simpler interfaces and you can just compose the parts you need.

Reply on news.ycombinator.com