[PATCH] D43578: -ftime-report switch support in Clang

[Kim Gräsman via Phabricator via cfe-commits]

kimgr added a comment.

Heh, my e-mail response was eaten along the way. Continued here:

On Sat, Apr 14, 2018 at 1:53 AM, Richard Smith - zygoloid via
Phabricator via cfe-commits <cfe-commits at 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!


https://reviews.llvm.org/D43578