[hellogcc] Fwd: Are we fast yet?
- From: Mingjie Xing <mingjie.xing@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Fri, 6 Jul 2012 16:05:37 +0800
http://teras-ics.mooo.com:8003/
---------- Forwarded message ----------
From: Dimitrios Apostolou <jimis@xxxxxxx>
Date: 2012/6/28
Subject: Are we fast yet?
To: gcc@xxxxxxxxxxx
抄送： Andrey Belevantsev <abel@xxxxxxxxx>
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
Other related posts:
