<div dir="ltr">It is indeed true that the features are overlapping. One thing I saw as an advantage of the proposed scheme over the existing /TIME is that, as Russell mentioned, the timer implementation is shared between the compiler and the linker. That enables us to use the same set of analysis tools for both. In fact, when you are doing LTO, the linker does compile bitcode into native code, in order to get unified timing info, we need to use the same time-trace framework.<div><br></div><div>JSON is not as easy to read as /TIME output as David pointed out. In particular, when an output is long and not intended, it is almost impossible to read. I wonder how much is that improved if we indent results (inserting a lot of newlines and space characters makes things slower, so we probably should do this only when the output filename is `-`). If it is still hard to read, we should consider adding a new feature to the time-trace framework to print out results in a more human-readable format.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 17, 2019 at 11:42 PM Russell Gallop via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></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">Hi David,<div><br></div><div>Thanks for the feedback.</div><div><br></div><div>> The COFF flavor of lld has an option to show basic timing information on stdout: <a href="https://llvm.org/r322736" target="_blank">https://llvm.org/r322736</a>. I enabled it on my project's CI and find it quite useful in logs. I'd be happy to see it ported to ELF.</div><div><br></div><div>It's interesting to compare. They're quite similar in implementation: using scoped timers. I wonder whether it would be possible to combine them with options to control level of tracing (fine or coarse), and how the output is produced (stdout or JSON). I think that would require more than just a time granularity control, maybe an indication of "level" on each trace analogous to logging levels.</div><div><br></div><div>One thing I like about the approach I propose here is that it is shared between the compiler and linker. It shares the timer implementation and makes the output more consistent for someone analysing a whole build.</div><div><br></div><div>> From looking at the screenshot on your review, it looks like your proposal provides much richer information, but the extra friction of opening a json file (and pulling it off our builders) means I'd be less inclined to reach for this feature unless I was debugging a specific issue.</div><div>> I guess it depends on whether you're going for day-to-day health monitoring or targeted problem-solving.<br></div><div><br></div><div>I think you're suggesting /TIME is better for day-to-day health monitoring and -time-trace for targeted problem-solving. I agree they have different strengths. On the compiler side I find that the JSON format is helpful for monitoring as well, as it's easier to automate checks and analysis from a machine readable format. Whatever approach does need to be low enough overhead to be useful in that way.</div><div><br></div><div>Regards</div><div>Russ</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 16 Oct 2019 at 18:15, David Major <<a href="mailto:dmajor@mozilla.com" target="_blank">dmajor@mozilla.com</a>> wrote:<br></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>The COFF flavor of lld has an option to show basic timing information on stdout: <a href="https://llvm.org/r322736" target="_blank">https://llvm.org/r322736</a>. I enabled it on my project's CI and find it quite useful in logs. I'd be happy to see it ported to ELF.<br></div><div><br></div><div>From looking at the screenshot on your review, it looks like your proposal provides much richer information, but the extra friction of opening a json file (and pulling it off our builders) means I'd be less inclined to reach for this feature unless I was debugging a specific issue. I guess it depends on whether you're going for day-to-day health monitoring or targeted problem-solving.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 11:34 AM Russell Gallop via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></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">Hi all,<div><br></div><div>I've been using -ftime-trace on the compiler and find it very useful for analysing compile times and whole build times. I've made a first attempt at adding this to LLD (ELF) so link times can be traced in the same way: <a href="https://reviews.llvm.org/D69043" target="_blank">https://reviews.llvm.org/D69043</a>  </div><div><br></div><div>This works for LTO and ThinLTO, but needs some more work to make sure it scales well across multiple threads.</div><div><br></div><div>Please let me know whether you think this is worth pursuing?</div><div><br></div><div>Thanks</div><div>Russ</div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>