sammccall added a comment. Thanks for all this investigation!
> 80.71 0.002330 5 394 374 openat I'm curious what the 400 attempts and 20 successes are (I've seen this before but don't remember now). Probably not worth digging into though unless you happen to have the strace logs. > buildCompilerInvocation usage inside scanPreamble doesn't need any access to > any files, so I suggest we just pass empty FS I guess this makes sense, My only worry is the driver getting into a different state if probing or cwd or something fails. But this really shouldn't affect preamble scanning. If it's safe, this seems worth doing just to have more isolation. > we need a different cache for buildCompilerInvocation, one that caches > dir_begin() failures Yeah this is complicated - worthwhile if the IO is actually adding ~20ms. Easiest way to tell if tracing tools aren't helping might be to use an empty FS and ignore all the resulting problems - timing for buildCompilerInvocation should be correct. If needed, maybe the record/replay FSes used for lldb reproducers are usable? Nice to avoid that complexity if possible though. > 48.73 2.244680 56 39747 tolower How many per call to buildCompilerInvocation? Maybe arg parsing is doing something dumb... Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81719/new/ https://reviews.llvm.org/D81719 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
