Hacker News new | past | comments | ask | show | jobs | submit login

Linkers have to copy large amount of data from object files to an output file, and that is inevitably slow. But LLD is not that bad if you pass -O0 (which disables string merging, which is computationally expensive). For example, LLD takes 6.7 seconds to link clang with debug info on my machine.

  $ time ld.lld <omit> -O0 -o bin/clang-4.0
  real    0m6.689s
Copying the output file to other file takes 2.6 seconds.

  $ time cp bin/clang-4.0 foo
  real    0m2.657s
So, LLD is only 2.5x slower than cp in this case. That's not too bad, as apparently the linker has many more things to do than the cp command.



Is your test mostly waiting on a mechanical hard drive? If so, then "2.5x slower than cp" could mean "a very large amount slower than cp" once you remove that overhead.

Whereas I have not done your specific test, I know that for the file sizes of executables I deal with in everyday work (around 10MB), the amount of time I wait for linking is woefully disproportionate.


For a comparison, an optimized release build of Clang 5.0 trunk (from a few days ago, built with Clang 5.0 trunk from like a week ago) with assertions enabled is 87mb -- with the LLVM libraries linked in, but dynamically linked to system libraries, on my Fedora 25 machine.

A debug build of clang is normally hundreds of megabytes (~600mb IIRC, and normal linkers go bonkers dealing with it), so if LLD is actually only 2.5x slower than 'cp' at -O0, that's quite good I think.

The next question is how much memory LLD uses vs the competition in this test...


It is on an SSD.


It'd be interesting to see the numbers of a ramdisk cp/link as well. With ssd being so much faster than mechanical disks, people sometimes forget that ram is faster still.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: