summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api/thread/main2.cpp
diff options
context:
space:
mode:
authorReid Kleckner <rnk@google.com>2018-11-27 19:00:23 +0000
committerReid Kleckner <rnk@google.com>2018-11-27 19:00:23 +0000
commit291d015de419bddc7c32d3e64682000b34dc4205 (patch)
treed04574ebf78bad1244bb2c3145086c3a36456965 /lldb/packages/Python/lldbsuite/test/python_api/thread/main2.cpp
parentf7d079e93e0ea6c97d03c917c4af9dd812bef2de (diff)
downloadbcm5719-llvm-291d015de419bddc7c32d3e64682000b34dc4205.tar.gz
bcm5719-llvm-291d015de419bddc7c32d3e64682000b34dc4205.zip
[PDB] Add symbol records in bulk
Summary: This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from 12.9s to 9.8s. Symbol records are typically small (16.7 bytes on average), but we processed them one at a time. CVSymbol is a relatively "large" type. It wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we don't need. Before this change, each DbiModuleDescriptorBuilder would maintain an array of CVSymbols, and would write them individually with a BinaryItemStream. With this change, we now add symbols that happen to appear contiguously in bulk. For each .debug$S section (roughly one per function), we allocate two copies, one for relocation, and one for realignment purposes. For runs of symbols that go in the module stream, which is most symbols, we now add them as a single ArrayRef<uint8_t>, so the vector DbiModuleDescriptorBuilder is roughly linear in the number of .debug$S sections (O(# funcs)) instead of the number of symbol records (very large). Some stats on symbol sizes for the curious: PDB size: 507M sym bytes: 316,508,016 sym count: 18,954,971 sym byte avg: 16.7 As future work, we may be able to skip copying symbol records in the linker for realignment purposes if we make LLVM write them aligned into the object file. We need to double check that such symbol records are still compatible with link.exe, but if so, it's definitely worth doing, since my profile shows we spend 500ms in memcpy in the symbol merging code. We could potentially cut that in half by saving a copy. Alternatively, we could apply the relocations *after* we iterate the symbols. This would require some careful re-engineering of the relocation processing code, though. Reviewers: zturner, aganea, ruiu Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54554 llvm-svn: 347687
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/python_api/thread/main2.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud