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.

[1] https://github.com/RazrFalcon/cargo-bloat

> 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++.