------------------------------------------------------------------------- Dependencies: This package requires the ELFIO package. You can find it on sourceforge. It is very easy to build using gcc. It requires a little work to compile it with KCC. Here are a few details: export CCC=KCC export CXX=KCC ./configure --prefix=whatever vi Makefile and ELFIO/Makefile Remove the Examples directory build from the Makefile. Change the definition of AR in ELFIO/Makefile to be AR = KCC $(CXXFLAGS) -o and change the rule to build libELFIO.a to run $(AR) like this $(AR) libELFIO.a $(libELFIO_a_OBJECTS) $(libELFIO_a_LIBADD) You should also install graphviz (from att research labs). This is each to install as an RPM under Linux. It is also very easy to get the source and build it yourself. To run the python utilities, you will need python 2.1 or higher set up. ------------------------------------------------------------------------- Building: If building with gcc, just type make in the perf_tools top directory. If building with KCC, you must edit mkinc and adjust the definitions at the front of the file. Then you can just type make. ------------------------------------------------------------------------- Limitations and problems: These tools will not work properly in multithreaded programs. Hopefully I will figure out a way to do this at some point. Running both the memory tool and the profiling tool at the same time is likely to exibit undefined behavior or data that is very difficult to understand. A program that forks without doing an exec is not properly handled. This is fairly easy to correct and the problem should be fixed soon. Proposed solution: intercept the fork call. shut down the profiler. do the fork. restart the profiler in the parent process. close the output file in the child process and open a new one, then restart profiling in the child. be careful to not flush buffered results to the output profile file in the child. be careful to junk buffered results in the childs profiling objects. The memory tool does not add a pid suffix to the output file name. A similar solution for forking must be added to the memory info collection tool. ------------------------------------------------------------------------- Instructions I sent out: I stopped in around 9:15, but you were not in yet. Here are a few instructions to try the prebuilt KCC version out on your machine. Get the tar file and untar it somewhere (the directory structure it produces is important). fcdflnx3:~jbk/downloads/perf_tools_binary.tar.gz Assuming that the untar is your home directory: cd ~ tar zxvf perf_tools_binary.tar.gz To run the profiler, do the something like the following, I assume that you untar'd the perf_tools into your home directory. cd "place where you run root from" ~/perf_tools/bin/RunProfiler.sh root -l MyRootScriptThing.C When it is done, there should be a set of binary profiling output files called "prof.out.XXX" where XXX is the process ID of a job. The bigger file is the one you want. There is another set of files called "prof_libs.out.XXX" where XXX is the process ID of a job. Lets assume that the bigger file has process ID 18620. Run the following command: ~/perf_tools/bin/ProfParse prof_libs.out.18620 prof.out.18620 X_ The last argument is a prefix that will be added to each of the files produced by the ProfParse program. This is a sampling based profiler, every 10ms the program takes a snapshot of the stack and records it. You should see the following files produced: X_names - one line per functions used by the program, a count of total times that this function was anywhere in a sample path, a count of the total times the sample taken was actually in this function. The file is sorted by the in-function count so that the functions that are hit most are at the top. X_paths - each unique path down to each function called (for graphing) X_totals - summary information X_edges - used by other tools To demangle the symbols in X_names, use the edg_decode utility for KCC programs or the c++filt program for gcc programs: edg_decode < X_names > X_names_decoded or c++filt < X_names > X_names_decoded You can determine some just by looking at the X_names file. To see call paths, we need to set up a few more things. I'll continue assuming that perf_tools is installed in ~/perf_tools. 1) get my compiled version of graphviz fcdflnx3:~/downloads/graphviz_binary.tar.gz 2) untar it in to the same place as the other perf_tools cd ~ untar zxvf graphviz_binary.tar.gz 3) setenv PATH ${PATH}:${HOME}/perf_tools/bin rehash 4) add to LD_LIBRARY_PATH (or set it to this if it is not set yet) ${HOME}/perf_tools/lib/graphviz The first column of the X_names file has the function ID. Find the ID of the function you want to plot. Lets assume it is ID 147. Run the following command. ProduceGraph.sh 147 0 The output should a bunch of files that begin with 147, one of which is 147.ps. Use ghostview to look at this figure. The second argument to ProduceGraph.sh is a cut parameter. If there is too much information included in the graph (lots of paths with one hit), then this parameter can be used to remove them. The meaning of the second parameter is to remove any paths that have hit counts < second_parameter This message hopefully explains the most basic features. There is more things to look at then just the "landed in this function count".