Hello list!
you may have thought I'd disappeared but here I am, after weeks of working
on a small project of mine. What started as a very small hack for
visualising callgrind's profiles is now an -experimental still- website, a
GCC version of mozilla's "arewefastyet.com". For now you can see it at:
http://teras-ics.mooo.com:8003/
Of course it has lots of problems so I'd appreciate all comments. Since
I didn't have a clue about web development, let's say that the UI is not
/that/ intuitive:
* The dots on the first plot are clickable and each open a different
profile breakdown.
* In each profile breakdown, functions are selectable and the blue thing
that shows at the bottom is actually a link (I know it doesn't show...)
that loads the same profile, but with the selected function as baseline.
* The profile breakdown CGI has also a hidden query string argument that I
couldn't find a nice way to expose in the SVG: &f=funcname selects the
function by name, e.g. if you want to find out the hottest callers for
malloc you can go to:
http://teras-ics.mooo.com:8003/cgi-bin/callgrind_svg.cgi?r=4.8-20120506&f=xmalloc
Many more small SVG issues took most of my time but I won't start here,
I'll save my wrath for the SVG-developers list. :-)
Besides the UI issues I still have some other open issues to think of,
ideas are welcome here too:
* Some function names are not demangled correctly, I'll first try
valgrind's trunk and maybe demangle anything that remains manually.
* Compile all GCC versions against specific glibc (and gmp/mpc/mpfr
secondly) to avoid fluctuations when the system upgrades. I've tried
linking statically and works well (as a bonus it also resolves all the
name mangling issues) but I'm really short on space now... so what's the
recommended way to link GCC against specific glibc (I was expecting some
--with-libc configure option)?
* Expose more of the data valgrind gives (like full source annotation)
* Unfortunately Callgrind doesn't save the full stack trace so what you
see is a statistical breakdown for callees. It doesn't necessarily mean
that a call path displayed actually exists deeper than its first level.
But the numbers add-up so this is minor.
So I started this thinking that there was not something similar for GCC.
Until I heard that http://gcc.opensuse.org actually measures compilation
time and memory usage a long time now. Hopefully this project of mine adds
some extra value by focusing cleanly on GCC's performance and by allowing
to actually spot the regressions easily.
To demonstrate this I annotated the frontpage plot manually, that is I
wrote the comments after diving into the callgraphs. It actually took only
a few minutes of switching tabs back and forth to notice the differences,
so I created the annotations as an example. (On another note this led me
to notice that a few patches of mine actually made it in trunk, cool. :-)
Last but not least credits to the websites that inspired me, namely
Mozilla's "arewefastyet.com" [1] and the original flamegraph at [2].
[1] http://arewefastyet.com/
[2]
http://dtrace.org/blogs/brendan/2012/03/17/linux-kernel-performance-flame-graphs/
Thanks,
Dimitris
P.S. For anyone interested, I've put the main source code -parsing of
Callgrind output and SVG generation, but /not/ the testing scripts/cron
jobs- in my private directory at Launchpad, but it's still very ugly and
hacky so beware:
http://bazaar.launchpad.net/~jimis/+junk/callgrind_parser/files