[PATCH] D27768: COFF: Open and map input files asynchronously on Windows.

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 14 11:00:19 PST 2016


pcc created this revision.
pcc added a reviewer: ruiu.
pcc added a subscriber: llvm-commits.
Herald added a subscriber: aemerson.

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.


https://reviews.llvm.org/D27768

Files:
  lld/COFF/Driver.cpp
  lld/COFF/Driver.h
  lld/COFF/InputFiles.cpp
  lld/COFF/InputFiles.h
  lld/COFF/SymbolTable.cpp
  lld/COFF/SymbolTable.h
  lld/COFF/Symbols.h
  lld/test/COFF/order.test

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D27768.81422.patch
Type: text/x-patch
Size: 20950 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161214/2fec4d51/attachment.bin>


More information about the llvm-commits mailing list