[PATCH] D155579: [Windows] Avoid using FileIndex for unique IDs on network mounts
Alexandre Ganea via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Aug 21 10:41:19 PDT 2023
aganea added a comment.
Unfortunately in our case the situation is even worse than what Martin was suggesting. My timings are 2x slower after this patch than without. Tested with a stage2 clang-cl built with ThinLTO and all optimizations on.
Build times for our game project, which is based on UE 5.2, on a 32c/64t Threadripper:
- before patch: 8 min 13 sec
- after patch: 15 min 20 sec
Same project, clang-scan-deps:
- before patch: 1 min 48 sec
- after patch: 3 min 47 sec
Even something as simple as that is slower after this patch:
PS C:\test> cat main.cpp
int main() { return 0; }
PS C:\test> Measure-Command { C:\before_patch\clang-cl.exe /c .\main.cpp }
...(omitted)...
TotalMilliseconds : 40.5117
PS C:\test> Measure-Command { C:\after_patch\clang-cl.exe /c .\main.cpp }
...(omitted)...
TotalMilliseconds : 57.4749
It seems one of root issues is the call to `GetVolumePathNameW` inside `is_local_internal`, which absolutely terrible. It generates 12 (!!!) separate kernel calls for each folder in the hierarchy. The deeper your files are, the longer it takes to execute.
Also worth noting that Clang calls `llvm::sys::status` twice:
- once in `DiagnoseInputExistence`.
- then in `FileSystemStatCache::get`.
Also these `status` calls are done on every single file or folder that Clang fiddles with, the sysroot folders, output files... Most of the time spent during our build is spent in the kernel (darker blue part): F28776054: image.png <https://reviews.llvm.org/F28776054>
If we had a resident daemon process that was caching inputs during the entire build, this patch wouldn't be an problem. One option like I was suggesting would be to hide this new behavior behind a (disabled) option, and tell users about it. But I'm not sure how useful it would be.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D155579/new/
https://reviews.llvm.org/D155579
More information about the llvm-commits
mailing list