|
From: Christoph B. <bar...@or...> - 2006-09-01 07:54:41
|
Hi, I am currently experimenting with callgrind. What is the correct way to achieve the following: Profile two different actions done in the same process and examine the profiles separately. Till now I would do: 1. Start the programm with --instr-atstart=no 2. Wait till programm flow reaches the desired state. 3. Start instrumenting: callgrind_control -i on 4. Start the first action. 5. Dump a profile: callgrind_control -d first 6. Start the second action. 7. Dump a profile: callgrind_control -d second 8. Stop instrumenting: callgrind_control -i off 9. Finish the programm. Is this correct? And how to get separate profiling sessions in kcachegrind? Does this work seamlessly with the -dump-every-bb option? Greetings Christoph Bartoschek |
|
From: Josef W. <Jos...@in...> - 2006-09-07 00:10:55
|
On Friday 01 September 2006 09:54, Christoph Bartoschek wrote: > Hi, >=20 > I am currently experimenting with callgrind. What is the correct way to=20 > achieve the following: >=20 > Profile two different actions done in the same process and examine the=20 > profiles separately. > > Till now I would do: >=20 > 1. Start the programm with --instr-atstart=3Dno > 2. Wait till programm flow reaches the desired state. > 3. Start instrumenting: callgrind_control -i on > 4. Start the first action. > 5. Dump a profile: callgrind_control -d first > 6. Start the second action. > 7. Dump a profile: callgrind_control -d second > 8. Stop instrumenting: callgrind_control -i off > 9. Finish the programm. That should do it. However, you probably are confusing "instrumentation off" with "collection of events off". The first includes the second, but also includes "cache simulation off" - which is perhaps not what you want: directly after (3), you will see a cache warmup phase with lots of cold misses, as the cache simulator starts with an empty cache. The only use of "instrumentation off" really is to speed up callgrind a lot on execution uninteresting code sections. The "collection off" is more or less a side effect of this "speedup" feature. Perhaps the following is better: (1) Start the program with callgrind (2) Wait for desired state, and zero counters (3) Run action, and dump counters afterwards =2E.. Depending on your needs, you can do the zeroing/dumping either with callgrind_control, with command options (--zero-before=3Dmyfunc), or with macros in your code (#include "callgrind.h"). Instead of "zero/dump counters", you could also switch collection state on/off. Eg. to only see the events happening between entering/leaving function "myfunc", do "... --collect-atstart=3Dno --toggle-collect=3Dmyfunc= ...".=20 > Is this correct? And how to get separate profiling sessions in kcachegrin= d? Every dump produces a new data file. kcachegrind does not have a special compare mode (yet). You have to load the 2 files into two kcachegrind windo= ws. It is a little bit involved to get source annotations for both old and new source versions nearside on the screen, as KCachegrind loads the source at visualization time; you need both old and new sources in diff= erent directories, and probably profile runs of different binaries where the debug information points to the different versions of the sources. This should be made easier; actually, callgrind_annotate is better for gene= rating source annotations which can be looked at later (after changing the code). To see the difference between an original code version and an optimized one= , it is better to have both in the code and execute them as action 1 and 2 in one program run (as you do). > Does this work seamlessly with the -dump-every-bb option? The effect of this option is some kind of rough interval aggregation, to see changes over time in one program run. The control over when a dump is happe= ning is not really good this way. Josef >=20 > Greetings > Christoph Bartoschek >=20 > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job ea= sier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users >=20 >=20 =2D-=20 Dr. Josef Weidendorfer LRR-TUM (Bode) - Raum 01.06.056 - Tel. +49 / (0)89 / 289 - 18454 Institut f=FCr Informatik, Technische Universit=E4t M=FCnchen |