←back to thread

Wild – A fast linker for Linux

(github.com)
383 points hkalbasi | 1 comments | 24 Jan 25 16:25 UTC | HN request time: 0.216s | source
Show context
bjourne ◴[24 Jan 25 21:25 UTC] No.42817059[source]▶
What a coincidence. :) Just an hour ago I compared the performance of wild, mold, and (plain-old) ld on a C project I'm working on. 23 kloc and 172 files. Takes about 23.4 s of user time to compile with gcc+ld, 22.5 s with gcc+mold, and 21.8 s with gcc+wild. Which leads me to believe that link time shouldn't be that much of a problem for well-structured projects.
replies(4): >>42817070 #>>42817177 #>>42817186 #>>42817193 #
davidlattimore ◴[24 Jan 25 21:41 UTC] No.42817186[source]▶
It sounds like you're building from scratch. In that case, the majority of the time will be spent compiling code, not linking. The case for fast linkers is strongest when doing iterative development. i.e. when making small changes to your code then rebuilding and running the result. With a small change, there's generally very little work for the compiler to do, but linking is still done from scratch, so tends to dominate.
replies(3): >>42819031 #>>42820402 #>>42822259 #
1. commandersaki ◴[25 Jan 25 02:51 UTC] No.42819031[source]▶
Yep in my case I have 11 * 450MB executables that take about 8 minutes to compile and link. But for small iterative programming cycles using the standard linker with g++, it takes about 30 seconds to link (If I remember correctly). I tried mold and shaved 25% of that time, which didn't seem worth the change overall; attempted wild a year ago but ran into issues, but will revisit at some point.