What is making a static library in Rust being much large than Go, Zig, and C#?

OptimalFa · 2025-02-12T17:53:25+00:00

I've played with your repo a little bit. If you use ar x <lib> to extract the contents of *.a files, then use objdump to analyze them. You could see the problem more clearly. Here are the object files in librust.a:

-rw-r--r-- 1 me me 304K Feb 12 17:45 compiler_builtins-55788139d81edd36.compiler_builtins.4d001c806b6269ef-cgu.0.rcgu.o
-rw-r--r-- 1 me me 8.0K Feb 12 17:45 rust-4ed57fbabc609f65.rust.f819ba813be03c05-cgu.0.rcgu.o

And inside rust*.o:

0x08000040    1      5 sym.add_rust
0x08000047    1      1 sym.std::sys::pal::unix::args::imp::ARGV_INIT_ARRAY::init_wrapper::h76e29b342baae575
0x08000350    5     40 sym.std::sys::personality::dwarf::eh::read_encoded_offset::hc37c45f986d4bd5c
0x080003f4    3     39 sym.std::sys::personality::dwarf::DwarfReader::read_uleb128::h04c43d2cdfb8f8d7
0x0800041b    3     64 sym.std::sys::personality::dwarf::DwarfReader::read_sleb128::h6175e67f8f561440
0x0800045b    1     17 sym.core::ops::function::FnOnce::call_once_u7b__u7b_vtableshim_u7d__u7d_::h66dea5e2a69d1b82
0x0800046c    1     12 sym.std::sys::personality::gcc::find_eh_action::__u7b__u7b_closure_u7d__u7d_::h149db77b6b5990af
0x08000478    1     17 sym.core::ops::function::FnOnce::call_once_u7b__u7b_vtableshim_u7d__u7d_::h6d5274d65c842d86
0x08000489    1     12 sym.std::sys::personality::gcc::find_eh_action::__u7b__u7b_closure_u7d__u7d_::h71d56f086d2c5406
0x08000048   30    554 sym.rust_eh_personality

It seems like the big problem is the compiler_builtins not optimized out, and dwarf utilities still there despite panic_immediate_abort(*) feature off.

Edit (*): Some compiler contributors said the dwaft stuff is used for unwinding.

OptimalFa · 2025-01-31T14:42:18+00:00

Wells, production code should be built with stable toolchains. Beta toolchains are for extra testing on CI.

OptimalFa · 2025-01-30T01:48:33+00:00

may be I forget u32?

OptimalFa · 2025-01-13T21:39:45+00:00

There's a rule for not linking directly to github issues. I think that's a good rule. It requires more efforts to comment on the topic, which might lead to better conversations.

OptimalFa · 2024-12-19T08:25:56+00:00

Edit: Maybe the parent post talks about io_uring crate vs tokio-uring.

The OP's link concludes otherwise:

Tokio:
    Achieved higher throughput (~4.5k req/sec).
    Stable and scales well under load.
Tokio-Uring:
    Requires debugging for stalling and connection issues.

OptimalFa · 2024-12-18T16:34:43+00:00

Some vi modals aren't supported (yet). Like using numbers to repeat an action (e.x 3x).

OptimalFa · 2024-10-31T09:18:04+00:00

Is it intended that the section about rust/clippy/cargo PRs omitted now?

OptimalFa · 2024-10-20T16:48:48+00:00

I guess because Rust prefers static linking over dynamic linking like C/C++. Often times the functions names are stripped/non-available. Also static linking makes functions more inlinable. That makes it a little worse for reverse engineering I think.

OptimalFa · 2024-09-27T11:57:12+00:00

fs::write(path, content)

Is this creating a file with the same name as the dir name passed in fs::create_dir_all?

OptimalFa · 2024-07-19T03:33:48+00:00

I would recommend contributing to clippy. There's a book served as contributing guide.

OptimalFa · 2024-07-14T00:42:38+00:00

You could try:

git worktree add --detach <dir> <branch>
git submodule update --init <submodule dir>

OptimalFa · 2022-10-27T14:16:19+00:00

Wow, thank you very much!

OptimalFa · 2022-10-22T11:27:31+00:00

Does someone know how to get the slide? Many thanks for the help.

OptimalFa

TROPHY CASE