<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><i>(I'm not familar with many/most of llvm/clang tooling, so some of my questions below might not make sense... bear with me)</i></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 dir="ltr"><div class="gmail_quote"> - the distinction between tracing/profiling automatically (stack frames, using xray or a profiler) and manually annotating ranges is an important one - it may be possible to use XRay to combine the two.<br></div></div></div></blockquote><div><br></div><div>Is Xray as "a general solution for this type of problem" general enough? From a quick glance, it seems to only work on Linux, which would exclude most of clang users who are on other OSes.</div><div><br></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 dir="ltr"><div class="gmail_quote"> - the timeline view, flame graph, and graphviz representations are independently useful, so being able to output something pprof can read is nice</div></div></div></blockquote><div><br></div><div>Agreed. I only did Chrome Tracing one because it's trivial to write, and a tool to view it exists on all OSes I care about. What other profiling output formats are "common enough" to have support for? I guess this might be highly industry specific (e.g. I haven't even heard of pprof before -- maybe because my work rarely if ever involves Linux).</div><div><br></div><div><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 dir="ltr"><div class="gmail_quote"> - for multi-threaded programs, being able to represent events split across or transferred between threads is important, but complicates the model</div></div></div></blockquote><div><br></div><div>Yeah. I thought about making it support multiple threads, but then seemingly all (or majority) of clang itself is single threaded. I found some utilities in llvm codebase (thread locals, thread pool etc.) but they seem to not be actually used in the whole codebase much.</div><div><br></div><div>For other implementations of a similar profiler  in other codebases that I've done, I approached the threading situation by having all profiler data be thread-local; that way profiler regions don't need to do any mutex locks; the only additional cost is a TLS lookup. And then "at the end" when profiling data is written into a file, which is required to happen when all thread work is done already, it just merges all the per-thread data and emits that. That is easy to implement and does not have high performance impact.</div><div><br></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 dir="ltr"><div class="gmail_quote"> - the chrome tracing format is pretty awkward to work with: bulky, odd semantics, doesn't survive truncation. It'd be nice to have something better.<br></div></div></div></blockquote><div><br></div><div>Similar to question before -- do you have suggestions for which format has readily available viewing tools (e.g. Speedoscope supports it, or similar -- <a href="https://github.com/jlfwong/speedscope">https://github.com/jlfwong/speedscope</a>), and is better?</div><div> </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></div>