What is left in such a binary? 800K of code seems on the high side even for a http framework.
While not answering the question directly, you can peek into Cargo.lock to see what all libraries are used by the project:
https://github.com/spacekookie/tinyrocket/blob/master/Cargo....
Of course what of those end up in the final binary is an open question. It would be kinda cool to see a dependency tree with size annotations, but I suppose that might be bit tricky to produce.
But I did find "cargo-bloat"[1] tool that gives following output:
File .text Size Name
4.8% 19.5% 98.2KiB core
4.0% 16.3% 81.9KiB std
3.9% 15.8% 79.4KiB rocket
2.4% 9.9% 49.9KiB hyper
2.0% 8.1% 40.6KiB [Unknown]
1.7% 7.0% 35.3KiB alloc
1.6% 6.5% 32.7KiB toml
1.1% 4.5% 22.5KiB url
1.0% 4.3% 21.4KiB yansi
0.5% 2.0% 9.9KiB tinyrocket
0.5% 1.8% 9.2KiB time
0.3% 1.3% 6.4KiB ring
0.2% 0.8% 3.8KiB ordermap
0.1% 0.5% 2.4KiB idna
0.1% 0.4% 1.8KiB percent_encoding
0.1% 0.4% 1.8KiB unicode_normalization
0.1% 0.3% 1.3KiB serde
0.1% 0.2% 1.2KiB std_unicode
0.0% 0.2% 880B pear
0.0% 0.1% 576B log
0.0% 0.1% 338B cookie
0.0% 0.1% 307B unwind
0.0% 0.0% 198B unicode_bidi
0.0% 0.0% 161B state
0.0% 0.0% 160B httparse
0.0% 0.0% 124B memchr
0.0% 0.0% 94B alloc_system
0.0% 0.0% 77B typeable
0.0% 0.0% 52B smallvec
0.0% 0.0% 45B compiler_builtins
0.0% 0.0% 28B rustc_tsan
0.0% 0.0% 25B unicase
0.0% 0.0% 11B panic_abort
0.0% 0.0% 11B panic_unwind
24.6% 100.0% 502.6KiB .text section size, the file size is 2.0MiB
When the stripped binary on my system is 979K. So it manages to account for about half of the binary size. From what is accounted, I suppose yansi (ANSI terminal lib) is the most superfluous, followed by toml parsing. Other than those, most of the stuff seems kinda relevant for a web framework.I'm now bit curious what the 979 - 502.6 = 476.4 remaining kilobytes are.. and totally nerdsniped. Running size gets me following:
[zokier@zarch tinyrocket]$ size -A -d target/release/tinyrocket
target/release/tinyrocket :
section size addr
.interp 28 624
.note.ABI-tag 32 652
.note.gnu.build-id 36 684
.gnu.hash 28 720
.dynsym 2568 752
.dynstr 1532 3320
.gnu.version 214 4852
.gnu.version_r 288 5072
.rela.dyn 40320 5360
.rela.plt 2328 45680
.init 23 48008
.plt 1568 48032
.plt.got 8 49600
.text 519185 49664
.fini 9 568852
.rodata 294652 568864
.eh_frame_hdr 15580 863516
.eh_frame 82544 879096
.tdata 48 3060064
.tbss 136 3060112
.init_array 8 3060112
.fini_array 8 3060120
.data.rel.ro 34984 3060128
.dynamic 576 3095112
.got 872 3095688
.data 201 3096576
.bss 464 3096784
.comment 69 0
Total 998309
So almost 290k in .rodata, that seems suspicious. Quick look at it shows about 17k of html as steveklabnik mentioned, but other than that I can't really identify any major blocks. I suppose this is the end of the dive, unless someone knows some tools to get more insight into .rodata data. I suppose in theory it should be possible to track down where in the code each bit of .rodata is accessed from, but that seems bit of a stretch.My tool Bloaty (https://github.com/google/bloaty) attempts to do exactly this. It even disassembles the binary looking for instructions that reference other sections like .rodata.
It doesn't currently know anything about Rust's name mangling scheme. I'd be happy to add this, though I suppose Rust's mangling is probably written in Rust and Bloaty is written in C++.