[PATCH] D63681: [clang-scan-deps] Introduce the DependencyScanning library with the thread worker code and better error handling

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added a subscriber: rnk.
aganea added a comment.

A bit more detail on what we're seeing on our end (specs in the post above). The 'Count' column represents the number of 1ms samples taken in that function. The 'Weight' column is cumulated times for all cores, for a given process, in ms.

Image below shows most of the time is spent in `clang-scan-deps.dll` and indirectly, in `ntoskrnl.exe`. The graph at the bottom also shows that preprocessing the ~600 unity .CPP files in the project issues 16 million IOPS. The graphs on the right show no bottlenecks on the disk I/O on the OS I/O-side.

F9417850: clang-scan-deps.jpg <https://reviews.llvm.org/F9417850>

Top functions in `ntoskrnl.exe`, most callstacks end up in `clang-scan-deps.dll`:

F9417863: clang-scan-deps2.jpg <https://reviews.llvm.org/F9417863>

A good chunk of all this is caused by `llvm::sys::status()`, even though is goes through the `FileSystemStatCache`, like I was suggesting previously <https://reviews.llvm.org/D63453#1547188> (ping @rnk)
//(beware, the callstacks are reversed in the image below)//

F9417870: clang-status.JPG <https://reviews.llvm.org/F9417870>

I can take a look at `llvm::sys::status()` after the vacations (somewhere in August)


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63681/new/

https://reviews.llvm.org/D63681