Are we fast yet?

[Dimitrios Apostolou <jimis at gmx dot net>]

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