After talking to a couple people at all-hands, it became clear that writing your own profiler was a popular activity.\u00a0 (Jeff Muizelaar informed me that last year, the pet project was heap analyzers.\u00a0 What’s next for 2012?)\u00a0 A short, non-exhaustive list:<\/p>\n
…and so forth.\u00a0 So it seemed like getting interested parties together to talk about One Profiler to Rule Them All would be good.\u00a0 And it worked; we had probably 20 people come to the BoF.\u00a0 Below is my summary\/recollection of what we discussed..\u00a0 All the omissions and\/or misrepresentation in the notes are my own; please leave a comment if you felt I left something out or need to describe something better.<\/p>\n
What does the ideal profiler look like?<\/p>\n
Bas Schouten also pointed out that it might be much more efficient to just buy suitable profiling technology from a vendor; there was some skepticism that a profiler fulfilling the desiderata existed, though.<\/p>\n
Since Benoit gave a demo of his profiler and his profiler seems likely to get into the tree, most of the discussion centered around that or variantions thereof.\u00a0 Benoit’s profiler works in the usual way via periodic signaling; however, instead of unwinding the call stack, Benoit chose to require annotations (via RAII objects) placed in various parts of the code to indicate what your “callstack” was when a sample was taken.\u00a0 I believe Steve said his profiler does something similar for JavaScript.\u00a0 I put “callstack” in quotes because you only get to know whether functions were on the call stack if annotations had been placed in them.<\/p>\n
Sprinkling annotations all over the tree sounded like a tedious process.\u00a0 Somebody pointed out that Chrome does this, though they only place annotations at “entry points” for modules, so you might have one entry point for layout, one for graphics, etc. etc.\u00a0 That way, given a profile on some random performance bug, you can at least tell who should be exploring the bug further with minimal overhead, since you’re not unwinding and a handful of RAII objects isn’t going to cost much.\u00a0 Granted, this doesn’t do much for the folks who need to dig deeper, but perhaps we can have other tools for that.<\/p>\n
There was some discussion of unwinding instead of annotations.\u00a0 Unwinding is reasonably cheap when using libunwind and caching decoding of the unwind information; it’s even cheaper when you can just walk frame pointers.\u00a0 The only wrinkle is you aren’t guaranteed to have frame pointers or unwind information on x86\/Linux, so unwinding is not generally doable there.\u00a0 Sometimes assembly coders also forget they need to insert unwind annotations, though most if not all of the problematic code in glibc, at least, has been so annotated.\u00a0 Taras Glek suggested that we could insert RAII objects before calling out to code that we don’t control and to make those objects record something about frame\/stack pointers so that we could unwind around third-party code if necessary.\u00a0 I don’t believe we came to a consensus on using unwinding instead of or in addition to annotations.<\/p>\n
I can’t recall if we talked extensively about unwinding through JavaScript code.<\/p>\n
We didn’t talk about displaying the collected data.\u00a0 Drawing pretty, understandable pictures is hard.<\/p>\n
Benoit and Steve agreed to talk further offline about modifying Benoit’s profiler to understand JavaScript; if you’d like to help with profilers, talk to either of them.\u00a0 It’d be great to have something in the tree that we can all work with and improve.<\/p>\n","protected":false},"excerpt":{"rendered":"
After talking to a couple people at all-hands, it became clear that writing your own profiler was a popular activity.\u00a0 (Jeff Muizelaar informed me that last year, the pet project was heap analyzers.\u00a0 What’s next for 2012?)\u00a0 A short, non-exhaustive list: Patrick Walton’s Piranha profiler for Android Benoit Girard’s Simple Profiling System Luke Wagner’s measure […]<\/p>\n","protected":false},"author":320,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/16"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/users\/320"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/comments?post=16"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/posts\/16\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/media?parent=16"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/categories?post=16"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nfroyd\/wp-json\/wp\/v2\/tags?post=16"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}