<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><i>I think the question is, "what next"? I don't really want to say "merge it right away!", because then we will have two systems for generating time reports, but I also don't want to send you off into the hills to refactor the existing Timer to support both output formats, and then decide what to do with all the fine-grained timers geared towards compiler developers. Would you be interested in working in that that direction, or would you rather hand the code off to someone else to try to integrate it more tightly?<br></i></div></blockquote><div><br></div><div>Good question.</div><div><br></div><div>I could take a stab at trying to make some sort of "one implementation" that could both generate the old -ftime-report report, and a hierarchical timeline / flame chart style one. But I've never worked with llvm/clang codebase, so I'd have some questions! The major one is:</div><div><br></div><div>- is it fine to change some interface (of e.g. Timer.h) and update all users inside LLVM monorepo to it? Or are there a million other projects using LLVM, with e.g. Timer.h being effectively an API that can't be changed?</div><div><br></div><div><br></div><div>Alternatively, I could make the whole change be contained just within clang itself. Right now I have put the new timer under llvm Support library, but I only use it in one place within llvm; all other usages are from within Clang only. It could almost just as well be some timer thing that only Clang uses. Not sure if that's worth doing or is easier accepted, vs. "the rest of llvm would want a timeline timer utility too". Thoughts?</div><div><br></div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><i>I feel like right now C++ users don't have a lot of visibility into build performance, so it ends up falling to specialist toolchain people to go and debug these problems. If we made it easy to see into the performance of compilation, it would democratize build time optimization, letting generalists do these kinds of codebase cleanups. At least, I hope it will. :)<br></i></div></div></blockquote><div><br></div><div>Indeed. A lot of "optimize C++ codebase compile times" is viewed as black box, also with quite a lot of myths and cargo culting from the inernet.</div><div><br></div><div>FWIW, Visual C++ has frontend timing report functionality too, but it was not documented at all. So I wrote about it a few days ago: <a href="http://aras-p.info/blog/2019/01/21/Another-cool-MSVC-flag-d1reportTime/">http://aras-p.info/blog/2019/01/21/Another-cool-MSVC-flag-d1reportTime/</a></div><div><br></div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Aras Pranckevičius<br>work: <a href="http://unity3d.com" target="_blank">http://unity3d.com</a><br>home: <a href="http://aras-p.info" target="_blank">http://aras-p.info</a></div><div dir="ltr" class="gmail_signature"><br></div></div></div>