mold is slower than default linking TiKV

[ethercflow]

Thanks for providing such a cool ld.

Environment: Ubuntu 20.04, 8 core intel processor, 16G memory, gcc 9.3.0, mold built from commit cb2b4b8.

I add

[target.x86_64-unknown-linux-gnu]
linker = "clang"
rustflags = ["-C", "link-arg=-fuse-ld=/path/to/mold"]

in ~/.cargo/config.toml

to test build TiKV 99b3436 with command make (It has been ensured that the required dependencies have been pulled locally before make), got the result:

• without mold (default ld): 23m 20s
• with mold: 24m 24s

[rui314]

Thank you for your report! What if you change one source file and rebuild? Is it slow too?

[ethercflow]

Thank you for your report! What if you change one source file and rebuild? Is it slow too?

Yes, it's slow too.

[rui314]

I built TiKV with cargo build, removed a generated target/debug/tikv-server (513MB in size) and run cargo build again. The file is regenerated in 0.29 seconds on my machine. So it doesn't seem mold is slow at linking the TiKV binary. Can you do the same to see if it is slow on your machine?

[rbartlensky]

I've tried this out myself and I got the following results:

tikv: https://github.com/tikv/tikv/commit/cc127a069496dea5f05b7e2a3816c66f9c3c7713 mold: https://github.com/rui314/mold/commit/b941a37b1e41ba01fea6994bdd8b2381907330dc

With bfd-ld:

• debug: Finished dev [unoptimized] target(s) in 3m 21s
• incremental: Finished dev [unoptimized] target(s) in 16.65s

With mold:

• debug: Finished dev [unoptimized] target(s) in 3m 08s
• incremental: Finished dev [unoptimized] target(s) in 2.68s

To trigger an incremental build I ran (since that makes cargo to only recompile the two binaries):

touch cmd/{tikv-ctl/src/main.rs,tikv-server/src/main.rs}

Also, @rui314 as an FYI, cargo won't trigger a recompilation (+ link) if you remove the binary. cargo likes to store the binary under a different name somewhere in ./target and if the final path is missing, cargo will simply copy the former back to the desired destination. The touch "method" seems to work well in this case.

[rui314]

Based on the confirmation, I'll close this as "not reproducible". Feel free to reopen if it still persists.

Also, @rui314 as an FYI, cargo won't trigger a recompilation (+ link) if you remove the binary. cargo likes to store the binary under a different name somewhere in ./target and if the final path is missing, cargo will simply copy the former back to the desired destination. The touch "method" seems to work well in this case.

Well noted!