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 <> 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!

cfe-commits mailing list

Reply via email to