6ee0b4e9f5
Profiling revealed that the majority of lld's execution time on Windows was spent opening and mapping input files. We can reduce this cost significantly by performing these operations asynchronously. This change introduces a queue for all operations on input file data. When we discover that we need to load a file (for example, when we find a lazy archive for an undefined symbol, or when we read a linker directive to load a file from disk), the file operation is launched using a future and the symbol resolution operation is enqueued. This implies another change to symbol resolution semantics, but it seems to be harmless ("ninja All" in Chromium still succeeds). To measure the perf impact of this change I linked Chromium's chrome_child.dll with both thin and fat archives. Thin archives: Before (median of 5 runs): 19.50s After: 10.93s Fat archives: Before: 12.00s After: 9.90s On Linux I found that doing this asynchronously had a negative effect on performance, probably because the cost of mapping a file is small enough that it becomes outweighed by the cost of managing the futures. So on non-Windows platforms I use the deferred execution strategy. Differential Revision: https://reviews.llvm.org/D27768 llvm-svn: 289760 |
||
---|---|---|
.. | ||
CMakeLists.txt | ||
Chunks.cpp | ||
Chunks.h | ||
Config.h | ||
DLL.cpp | ||
DLL.h | ||
Driver.cpp | ||
Driver.h | ||
DriverUtils.cpp | ||
Error.cpp | ||
Error.h | ||
ICF.cpp | ||
InputFiles.cpp | ||
InputFiles.h | ||
Librarian.cpp | ||
MarkLive.cpp | ||
ModuleDef.cpp | ||
Options.td | ||
PDB.cpp | ||
PDB.h | ||
README.md | ||
Strings.cpp | ||
Strings.h | ||
SymbolTable.cpp | ||
SymbolTable.h | ||
Symbols.cpp | ||
Symbols.h | ||
Writer.cpp | ||
Writer.h |
README.md
See docs/NewLLD.rst