Very nice. There's a small problem when there are more than 10000 functions. At least some versions of gprof have a bug where the initial function index loses the closing bracket for indices > 10000. I just added a '?' to the initial closing bracket in the cg_primary_re and cg_cycle_header_re regexps to fix this.
It would be very nice to have an option to colour nodes according to exclusive time rather than inclusive - having the main red hotspot "main" for every profile is not always helpful
Amazing, I finally find the tool I needed:) Is it possible to let user specify the function to output? I think it would be better if user can specify one function so to see the process flow of a specific function. For example,one program has 2 steps one is compressing and the following is decompressing,so the user can choose to draw only the work flow of decompressing.
Comment by jon.x.hill, May 22, 2009 It would be very nice to have an option to colour nodes according to exclusive time rather than inclusive - having the main red hotspot "main" for every profile is not always helpful
I think you can achive this by simply copy it to another one say,gprof2dot2.py and then goto line 1898,modify it as below actually changing PRUNE_RATION to TIME_RATIO, hope the author will give one option for this:)
When I run it as below, I do get some graph output, I wonder if this is a correct graph. I am using -pg option in my CFLAGS and LDFLAGS options.
i.e. I did:
$ gprof my_exec > gprof_out.txt $ ./gprof2dot.py -f prof gprof_out.txt | dot -Tpng -o goutput.png This gives me a viewable goutput.png graph but I am wondering if there could be a "prof vs. gprof" confusion in my commandline, that makes this illegitimate.
I added the following line to the PstatsParser?.parse method in order to print summaries information, in particular the cpu time. Maybe maybe it could be useful to someone else...
print >> sys.stderr, "%s function calls" % (self.stats.total_calls),
if self.stats.total_calls != self.stats.prim_calls:
Nice job of programming, but this kind of gprof-style stuff gives me a stomach ache, because I use the random-pause method of locating "bottlenecks". Gprof floods you with data, of which 95+% is irrelevant. For example, I worked through that gmon.out data and simulated 10 random stack samples. After sorting them, they look like this:
main ...
main read_all_makefiles ...
main read_all_makefiles eval_makefile eval ...
main read_all_makefiles eval_makefile eval ...
main read_all_makefiles eval_makefile eval ...
main read_all_makefiles eval_makefile eval ...
main update_goal_chain ...
main update_goal_chain try_implicit_rule ...
main update_goal_chain try_implicit_rule pattern_search ...
main update_goal_chain try_implicit_rule pattern_search file_impossible_p find_directory ...
The ... is because I couldn't follow the gmon.out data far enough to simulate a full stack trace. Any routine on X% of these samples is responsible for about X% of the time. Examples:
What's more the exact lines of code responsible for the time are also on the samples, not just functions. This a small amount of data, and it is rich in information about what code is responsible for the time. It doesn't spend a lot of clutter on stuff that doesn't matter. What's more, gprof is blind to I/O, so it is skewed to CPU-only time, not wall time.
This is a tool to help visualize "gprof-style stuff". I never intended to advocate nor evangelize gprof (which I actually stopped many years ago), any particular profiling tool, or even a particular profiling technique. This tool, like any tool, it is merely is a mean to an end, and is not implicitly good or bad. If this tool doesn't fit your needs then you can simply be kind to your stomach and not use it.
Yes, the results will be blind to I/O if the profiler is blind to I/O. But this is not the case with all profilers (e.g., Very Sleepy will capture I/O times when profiling a single thread). Tools like xperf and linux perf can actually put a maginifying glass on events such as I/O or context switches.
Yes, gprof and similar profilers will flood you with a lot of data. But guess what -- reducing the data and higlighting the most interesting bits is precisely the point of this tool. Actually, if you look at the output, and follow the hot red color down you'll get precisely the call path that "random-pause" most frequently would give (assuming load is CPU based or the tool captures I/O times) if there is one. If there is not single hot path, you still perceive informatiom without doing many "random-pauses" (which, if done too often, end up being nothing more than a poor man sampling profiler).
One thing which you hint at, and that I agree that could be done better here is to take in account the full stack traces. Unlike old gprof, new tools such as linux perf and Very Sleepy capture the full stack traces, however gprof2dot ends up ignoring the high order correlations, which ends up biasing (actually more like tends to averaging out) the cumulative values.
There is some challenge though, as stack traces are some times truncated, so a mixed approach will be necessary. Also, this only makes a significant difference when there are dispatch functions, i.e., single functions with many callers and many callees, that dispatch to a particular callee depending on argument input.
hi, i tested gprof on c++ code, but in the call graph are value for % time--self--children = ZERO, do you know where is problem ? for example: index % time self children called name
Awesome tool. One request though (I'd do it myself, but I'm really rusty with python) would be to have a command-option to strip certain function names, or function names that match a particular wildcard string. My call graph is being cluttered with a large abundance of mathlib and other lower-level stuff, when all I'm really interested in are the routines internal to my program. Ideally, this command-line option would be able to be passed multiple times to accumulate a list of patterns to exclude.
I just could not depart your website prior to suggesting that I really enjoyed the usual info an individual provide on your guests? Is gonna be back often in order to check up on new posts
Great job José. Thanks for making it available to all of us!
I just wanted to let you know that this script just saved me hours of deciphering the Python profiler's output. Thanks!
excellent work!! thanks a lot!
Excellent python profiling result viewer. I'm using inkscape as an SVG visualization tool (couldn't find easily a dot viewer on Windows).
It's just what I was looking for. Thanks.
Very nice. There's a small problem when there are more than 10000 functions. At least some versions of gprof have a bug where the initial function index loses the closing bracket for indices > 10000. I just added a '?' to the initial closing bracket in the cg_primary_re and cg_cycle_header_re regexps to fix this.
Here is an example of the gprof bug:
----------------------------------------------- 0.00 0.00 3778/3778 timing::ClockDef::~ClockDef() [3176] [9999] 0.0 0.00 0.00 3778 timing::ClockEdge::~ClockEdge() [9999] ----------------------------------------------- 0.00 0.00 14/3657 timing::BaseTranList::handleUserTransitions(clkdb::SmartPointerTP<circuit::Port>, bool) [836] 0.00 0.00 3643/3657 timing::AllClockDefs::skipClockPropDueToInactiveClock(clkdb::SmartPointerTP<timing::ClockDef>) [2467] [10000 0.0 0.00 0.00 3657 timing::ClockDef::getMasterSourceClock() const [10000] ----------------------------------------------- 0.00 0.00 3503/3503 circuit::name::FindNameBaseTraverser::addFoundName(clkdb::SmartPointerTP<circuit::name::NameIFC>, clkdb::SmartPointerTP<clkdb::PersistentObject>) [2984] [10001 0.0 0.00 0.00 3503 circuit::name::FindNameContainer<clkdb::ObjectContainer>::push_back(clkdb::SmartPointerTP<clkdb::PersistentObject>) [10001] -----------------------------------------------jkuzeja,
Commited. Thanks.
Very nice, thanks!
/Johan Eker
It would be very nice to have an option to colour nodes according to exclusive time rather than inclusive - having the main red hotspot "main" for every profile is not always helpful
Really quality tools man...
This is a life saver....great job.
This is an excellent program. Thank you very much for your hard work.
Amazing, I finally find the tool I needed:) Is it possible to let user specify the function to output? I think it would be better if user can specify one function so to see the process flow of a specific function. For example,one program has 2 steps one is compressing and the following is decompressing,so the user can choose to draw only the work flow of decompressing.
Comment by jon.x.hill, May 22, 2009 It would be very nice to have an option to colour nodes according to exclusive time rather than inclusive - having the main red hotspot "main" for every profile is not always helpful
I think you can achive this by simply copy it to another one say,gprof2dot2.py and then goto line 1898,modify it as below actually changing PRUNE_RATION to TIME_RATIO, hope the author will give one option for this:)
Is there any chance for valgrind callgrind support? These graphs are much nicer than some of KCacheGrind's.
Hi,
I tried using the gprof2dot script with my attached output and I got an error below.
i.e. I did this on Fedora:
$.my_exec param1 param2 $ gprof my_exec | gprof2dot.py | dot -Tpng -o output.png
I got:
Error: <stdin>:1: syntax error near line 1 context: >>> Command <<< not found.
Any ideas on what I did wrong? I am running Fedora 12 virtualized on my OS X (leopard). Any ideas will be appreciated,
Ad.
All,
When I run it as below, I do get some graph output, I wonder if this is a correct graph. I am using -pg option in my CFLAGS and LDFLAGS options.
i.e. I did:
$ gprof my_exec > gprof_out.txt $ ./gprof2dot.py -f prof gprof_out.txt | dot -Tpng -o goutput.png This gives me a viewable goutput.png graph but I am wondering if there could be a "prof vs. gprof" confusion in my commandline, that makes this illegitimate.
Thanks, Ad.
would you please update the documentation for processing sysprof results? Thanks!
I added the following line to the PstatsParser?.parse method in order to print summaries information, in particular the cpu time. Maybe maybe it could be useful to someone else...
It could be nice to include summaries information in the output image.
Thank you very much for the tool. I tried it for Python and it is great; hope it handle oProfile output the same good.
a wonderful tool
Nice job of programming, but this kind of gprof-style stuff gives me a stomach ache, because I use the random-pause method of locating "bottlenecks". Gprof floods you with data, of which 95+% is irrelevant. For example, I worked through that gmon.out data and simulated 10 random stack samples. After sorting them, they look like this:
The ... is because I couldn't follow the gmon.out data far enough to simulate a full stack trace. Any routine on X% of these samples is responsible for about X% of the time. Examples:
What's more the exact lines of code responsible for the time are also on the samples, not just functions. This a small amount of data, and it is rich in information about what code is responsible for the time. It doesn't spend a lot of clutter on stuff that doesn't matter. What's more, gprof is blind to I/O, so it is skewed to CPU-only time, not wall time.
MikeDunlavey?,
This is a tool to help visualize "gprof-style stuff". I never intended to advocate nor evangelize gprof (which I actually stopped many years ago), any particular profiling tool, or even a particular profiling technique. This tool, like any tool, it is merely is a mean to an end, and is not implicitly good or bad. If this tool doesn't fit your needs then you can simply be kind to your stomach and not use it.
Yes, the results will be blind to I/O if the profiler is blind to I/O. But this is not the case with all profilers (e.g., Very Sleepy will capture I/O times when profiling a single thread). Tools like xperf and linux perf can actually put a maginifying glass on events such as I/O or context switches.
Yes, gprof and similar profilers will flood you with a lot of data. But guess what -- reducing the data and higlighting the most interesting bits is precisely the point of this tool. Actually, if you look at the output, and follow the hot red color down you'll get precisely the call path that "random-pause" most frequently would give (assuming load is CPU based or the tool captures I/O times) if there is one. If there is not single hot path, you still perceive informatiom without doing many "random-pauses" (which, if done too often, end up being nothing more than a poor man sampling profiler).
One thing which you hint at, and that I agree that could be done better here is to take in account the full stack traces. Unlike old gprof, new tools such as linux perf and Very Sleepy capture the full stack traces, however gprof2dot ends up ignoring the high order correlations, which ends up biasing (actually more like tends to averaging out) the cumulative values.
There is some challenge though, as stack traces are some times truncated, so a mixed approach will be necessary. Also, this only makes a significant difference when there are dispatch functions, i.e., single functions with many callers and many callees, that dispatch to a particular callee depending on argument input.
hi, i tested gprof on c++ code, but in the call graph are value for % time--self--children = ZERO, do you know where is problem ? for example: index % time self children called name
2? 0.0 0.00 0.00 1+9 quicksort(int, int, int) 2?thx. V.
I love this. This is the best thing ever.
The new subgraph feature is very cool!! Thanks so much. this is great for analyzing code, results are like an automatic flowchart.
Amazing!
thanks!
Thanks, this thing is that I need.
Awesome tool. One request though (I'd do it myself, but I'm really rusty with python) would be to have a command-option to strip certain function names, or function names that match a particular wildcard string. My call graph is being cluttered with a large abundance of mathlib and other lower-level stuff, when all I'm really interested in are the routines internal to my program. Ideally, this command-line option would be able to be passed multiple times to accumulate a list of patterns to exclude.
Russel's blog for java hprof has moved to http://rjp.io/blog/?p=146
Summary
And a followup to my previous comment. I'm actually profiling java under the play framework via the java hprof.
I was getting error: unexpected end of file until I passed an explicit file type.
thanks a lot for your script, its really good for a "human-readable" visualization xd, you'll be in my thesis's acknowledgements :)
The script is what? Please explain to me, because I want in depth http://wdfshare.blogspot.com
thanks for sharing. I'm waiting next article again http://mr-yellows.blogspot.com/2015/02/klikofficecoid-belanja-online-peralatan-dan-perlengkapan-kantor.html
I just could not depart your website prior to suggesting that I really enjoyed the usual info an individual provide on your guests? Is gonna be back often in order to check up on new posts
upsee.nic.in