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

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: