Hi Richard, On Sat, Apr 14, 2018 at 1:53 AM, Richard Smith - zygoloid via Phabricator via cfe-commits <cfe-commits@lists.llvm.org> wrote: > rsmith added a comment. > > So I don't think this patch is reasonable for that reason. I'm also not sure > whether this, as is, is addressing a pressing use case -- for Clang > developers, existing non-invasive profiling tools (such as linux-perftools) > are likely to work a lot better for identifying where in the Clang source > code we're spending time. And Clang users typically don't care which function > we're in (unless they're filing a bug, where again a profiler is probably a > better tool). > > However, I do think we could make `-ftime-report` vastly more useful to Clang > users. Specifically, I think the useful, actionable feedback we can give to > users would be to tell them which parts of //their source code// are taking a > long time to compile. Profiling information that can describe -- for instance > -- the time spent instantiating the N slowest templates, or handling the N > slowest functions, or evaluating the N slowest constant expressions, or > parsing the N slowest `#include`d files, seems like it would be incredibly > valuable. To make that work, I think we'll need to teach LLVM's timer > infrastructure to properly separate out "self" time from "children" time for > timers in the same group, and may need other infrastructure improvements.
I disagreed up until the last paragraph :) That's exactly the crux of what most users need to know -- which parts of my source code are causing the biggest build slow-down? The summary information from -ftime-report can give a hint, but a detailed breakdown would of course be great! - Kim _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
