←back to thread

383 points hkalbasi | 2 comments | | HN request time: 0.001s | source
Show context
bjourne ◴[] 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 ◴[] 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. bjourne ◴[] No.42822259[source]
True, I didn't think of that. However, the root cause here perhaps is fat binaries? My preferred development flow consists of many small self-contained dynamically linked libraries that executables link to. Then you only have to relink changed libraries and not executables that depend on them.
replies(1): >>42823278 #
2. iknowstuff ◴[] No.42823278[source]
So is this your preferred flow because of slow linkers?