diff options
Diffstat (limited to 'Doc/libprofile.tex')
| -rw-r--r-- | Doc/libprofile.tex | 767 |
1 files changed, 0 insertions, 767 deletions
diff --git a/Doc/libprofile.tex b/Doc/libprofile.tex deleted file mode 100644 index 61da988..0000000 --- a/Doc/libprofile.tex +++ /dev/null @@ -1,767 +0,0 @@ -\chapter{The Python Profiler} -\label{profile} - -Copyright \copyright{} 1994, by InfoSeek Corporation, all rights reserved. -\index{InfoSeek Corporation} - -Written by James Roskind\index{Roskind, James}.% -\footnote{ -Updated and converted to \LaTeX\ by Guido van Rossum. The references to -the old profiler are left in the text, although it no longer exists. -} - -Permission to use, copy, modify, and distribute this Python software -and its associated documentation for any purpose (subject to the -restriction in the following sentence) without fee is hereby granted, -provided that the above copyright notice appears in all copies, and -that both that copyright notice and this permission notice appear in -supporting documentation, and that the name of InfoSeek not be used in -advertising or publicity pertaining to distribution of the software -without specific, written prior permission. This permission is -explicitly restricted to the copying and modification of the software -to remain in Python, compiled Python, or other languages (such as C) -wherein the modified or derived code is exclusively imported into a -Python module. - -INFOSEEK CORPORATION DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS -SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND -FITNESS. IN NO EVENT SHALL INFOSEEK CORPORATION BE LIABLE FOR ANY -SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER -RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF -CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN -CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. - - -The profiler was written after only programming in Python for 3 weeks. -As a result, it is probably clumsy code, but I don't know for sure yet -'cause I'm a beginner :-). I did work hard to make the code run fast, -so that profiling would be a reasonable thing to do. I tried not to -repeat code fragments, but I'm sure I did some stuff in really awkward -ways at times. Please send suggestions for improvements to: -\email{jar@netscape.com}. I won't promise \emph{any} support. ...but -I'd appreciate the feedback. - - -\section{Introduction to the profiler} -\nodename{Profiler Introduction} - -A \dfn{profiler} is a program that describes the run time performance -of a program, providing a variety of statistics. This documentation -describes the profiler functionality provided in the modules -\module{profile} and \module{pstats}. This profiler provides -\dfn{deterministic profiling} of any Python programs. It also -provides a series of report generation tools to allow users to rapidly -examine the results of a profile operation. -\index{deterministic profiling} -\index{profiling, deterministic} - - -\section{How Is This Profiler Different From The Old Profiler?} -\nodename{Profiler Changes} - -(This section is of historical importance only; the old profiler -discussed here was last seen in Python 1.1.) - -The big changes from old profiling module are that you get more -information, and you pay less CPU time. It's not a trade-off, it's a -trade-up. - -To be specific: - -\begin{description} - -\item[Bugs removed:] -Local stack frame is no longer molested, execution time is now charged -to correct functions. - -\item[Accuracy increased:] -Profiler execution time is no longer charged to user's code, -calibration for platform is supported, file reads are not done \emph{by} -profiler \emph{during} profiling (and charged to user's code!). - -\item[Speed increased:] -Overhead CPU cost was reduced by more than a factor of two (perhaps a -factor of five), lightweight profiler module is all that must be -loaded, and the report generating module (\module{pstats}) is not needed -during profiling. - -\item[Recursive functions support:] -Cumulative times in recursive functions are correctly calculated; -recursive entries are counted. - -\item[Large growth in report generating UI:] -Distinct profiles runs can be added together forming a comprehensive -report; functions that import statistics take arbitrary lists of -files; sorting criteria is now based on keywords (instead of 4 integer -options); reports shows what functions were profiled as well as what -profile file was referenced; output format has been improved. - -\end{description} - - -\section{Instant Users Manual} - -This section is provided for users that ``don't want to read the -manual.'' It provides a very brief overview, and allows a user to -rapidly perform profiling on an existing application. - -To profile an application with a main entry point of \samp{foo()}, you -would add the following to your module: - -\begin{verbatim} -import profile -profile.run('foo()') -\end{verbatim} -% -The above action would cause \samp{foo()} to be run, and a series of -informative lines (the profile) to be printed. The above approach is -most useful when working with the interpreter. If you would like to -save the results of a profile into a file for later examination, you -can supply a file name as the second argument to the \function{run()} -function: - -\begin{verbatim} -import profile -profile.run('foo()', 'fooprof') -\end{verbatim} -% -The file \file{profile.py} can also be invoked as -a script to profile another script. For example: - -\begin{verbatim} -python /usr/local/lib/python1.5/profile.py myscript.py -\end{verbatim} - -When you wish to review the profile, you should use the methods in the -\module{pstats} module. Typically you would load the statistics data as -follows: - -\begin{verbatim} -import pstats -p = pstats.Stats('fooprof') -\end{verbatim} -% -The class \class{Stats} (the above code just created an instance of -this class) has a variety of methods for manipulating and printing the -data that was just read into \samp{p}. When you ran -\function{profile.run()} above, what was printed was the result of three -method calls: - -\begin{verbatim} -p.strip_dirs().sort_stats(-1).print_stats() -\end{verbatim} -% -The first method removed the extraneous path from all the module -names. The second method sorted all the entries according to the -standard module/line/name string that is printed (this is to comply -with the semantics of the old profiler). The third method printed out -all the statistics. You might try the following sort calls: - -\begin{verbatim} -p.sort_stats('name') -p.print_stats() -\end{verbatim} -% -The first call will actually sort the list by function name, and the -second call will print out the statistics. The following are some -interesting calls to experiment with: - -\begin{verbatim} -p.sort_stats('cumulative').print_stats(10) -\end{verbatim} -% -This sorts the profile by cumulative time in a function, and then only -prints the ten most significant lines. If you want to understand what -algorithms are taking time, the above line is what you would use. - -If you were looking to see what functions were looping a lot, and -taking a lot of time, you would do: - -\begin{verbatim} -p.sort_stats('time').print_stats(10) -\end{verbatim} -% -to sort according to time spent within each function, and then print -the statistics for the top ten functions. - -You might also try: - -\begin{verbatim} -p.sort_stats('file').print_stats('__init__') -\end{verbatim} -% -This will sort all the statistics by file name, and then print out -statistics for only the class init methods ('cause they are spelled -with \samp{__init__} in them). As one final example, you could try: - -\begin{verbatim} -p.sort_stats('time', 'cum').print_stats(.5, 'init') -\end{verbatim} -% -This line sorts statistics with a primary key of time, and a secondary -key of cumulative time, and then prints out some of the statistics. -To be specific, the list is first culled down to 50\% (re: \samp{.5}) -of its original size, then only lines containing \code{init} are -maintained, and that sub-sub-list is printed. - -If you wondered what functions called the above functions, you could -now (\samp{p} is still sorted according to the last criteria) do: - -\begin{verbatim} -p.print_callers(.5, 'init') -\end{verbatim} - -and you would get a list of callers for each of the listed functions. - -If you want more functionality, you're going to have to read the -manual, or guess what the following functions do: - -\begin{verbatim} -p.print_callees() -p.add('fooprof') -\end{verbatim} -% -\section{What Is Deterministic Profiling?} -\nodename{Deterministic Profiling} - -\dfn{Deterministic profiling} is meant to reflect the fact that all -\dfn{function call}, \dfn{function return}, and \dfn{exception} events -are monitored, and precise timings are made for the intervals between -these events (during which time the user's code is executing). In -contrast, \dfn{statistical profiling} (which is not done by this -module) randomly samples the effective instruction pointer, and -deduces where time is being spent. The latter technique traditionally -involves less overhead (as the code does not need to be instrumented), -but provides only relative indications of where time is being spent. - -In Python, since there is an interpreter active during execution, the -presence of instrumented code is not required to do deterministic -profiling. Python automatically provides a \dfn{hook} (optional -callback) for each event. In addition, the interpreted nature of -Python tends to add so much overhead to execution, that deterministic -profiling tends to only add small processing overhead in typical -applications. The result is that deterministic profiling is not that -expensive, yet provides extensive run time statistics about the -execution of a Python program. - -Call count statistics can be used to identify bugs in code (surprising -counts), and to identify possible inline-expansion points (high call -counts). Internal time statistics can be used to identify ``hot -loops'' that should be carefully optimized. Cumulative time -statistics should be used to identify high level errors in the -selection of algorithms. Note that the unusual handling of cumulative -times in this profiler allows statistics for recursive implementations -of algorithms to be directly compared to iterative implementations. - - -\section{Reference Manual} -\stmodindex{profile} -\label{module-profile} - - -The primary entry point for the profiler is the global function -\function{profile.run()}. It is typically used to create any profile -information. The reports are formatted and printed using methods of -the class \class{pstats.Stats}. The following is a description of all -of these standard entry points and functions. For a more in-depth -view of some of the code, consider reading the later section on -Profiler Extensions, which includes discussion of how to derive -``better'' profilers from the classes presented, or reading the source -code for these modules. - -\begin{funcdesc}{run}{string\optional{, filename\optional{, ...}}} - -This function takes a single argument that has can be passed to the -\keyword{exec} statement, and an optional file name. In all cases this -routine attempts to \keyword{exec} its first argument, and gather profiling -statistics from the execution. If no file name is present, then this -function automatically prints a simple profiling report, sorted by the -standard name string (file/line/function-name) that is presented in -each line. The following is a typical output from such a call: - -\begin{verbatim} - main() - 2706 function calls (2004 primitive calls) in 4.504 CPU seconds - -Ordered by: standard name - -ncalls tottime percall cumtime percall filename:lineno(function) - 2 0.006 0.003 0.953 0.477 pobject.py:75(save_objects) - 43/3 0.533 0.012 0.749 0.250 pobject.py:99(evaluate) - ... -\end{verbatim} - -The first line indicates that this profile was generated by the call:\\ -\code{profile.run('main()')}, and hence the exec'ed string is -\code{'main()'}. The second line indicates that 2706 calls were -monitored. Of those calls, 2004 were \dfn{primitive}. We define -\dfn{primitive} to mean that the call was not induced via recursion. -The next line: \code{Ordered by:\ standard name}, indicates that -the text string in the far right column was used to sort the output. -The column headings include: - -\begin{description} - -\item[ncalls ] -for the number of calls, - -\item[tottime ] -for the total time spent in the given function (and excluding time -made in calls to sub-functions), - -\item[percall ] -is the quotient of \code{tottime} divided by \code{ncalls} - -\item[cumtime ] -is the total time spent in this and all subfunctions (i.e., from -invocation till exit). This figure is accurate \emph{even} for recursive -functions. - -\item[percall ] -is the quotient of \code{cumtime} divided by primitive calls - -\item[filename:lineno(function) ] -provides the respective data of each function - -\end{description} - -When there are two numbers in the first column (e.g.: \samp{43/3}), -then the latter is the number of primitive calls, and the former is -the actual number of calls. Note that when the function does not -recurse, these two values are the same, and only the single figure is -printed. - -\end{funcdesc} - -Analysis of the profiler data is done using this class from the -\module{pstats} module: - -% now switch modules.... -\stmodindex{pstats} - -\begin{classdesc}{Stats}{filename\optional{, ...}} -This class constructor creates an instance of a ``statistics object'' -from a \var{filename} (or set of filenames). \class{Stats} objects are -manipulated by methods, in order to print useful reports. - -The file selected by the above constructor must have been created by -the corresponding version of \module{profile}. To be specific, there is -\emph{no} file compatibility guaranteed with future versions of this -profiler, and there is no compatibility with files produced by other -profilers (e.g., the old system profiler). - -If several files are provided, all the statistics for identical -functions will be coalesced, so that an overall view of several -processes can be considered in a single report. If additional files -need to be combined with data in an existing \class{Stats} object, the -\method{add()} method can be used. -\end{classdesc} - - -\subsection{The \module{Stats} Class} - -\setindexsubitem{(Stats method)} - -\begin{methoddesc}{strip_dirs}{} -This method for the \class{Stats} class removes all leading path -information from file names. It is very useful in reducing the size -of the printout to fit within (close to) 80 columns. This method -modifies the object, and the stripped information is lost. After -performing a strip operation, the object is considered to have its -entries in a ``random'' order, as it was just after object -initialization and loading. If \method{strip_dirs()} causes two -function names to be indistinguishable (i.e., they are on the same -line of the same filename, and have the same function name), then the -statistics for these two entries are accumulated into a single entry. -\end{methoddesc} - - -\begin{methoddesc}{add}{filename\optional{, ...}} -This method of the \class{Stats} class accumulates additional -profiling information into the current profiling object. Its -arguments should refer to filenames created by the corresponding -version of \function{profile.run()}. Statistics for identically named -(re: file, line, name) functions are automatically accumulated into -single function statistics. -\end{methoddesc} - -\begin{methoddesc}{sort_stats}{key\optional{, ...}} -This method modifies the \class{Stats} object by sorting it according -to the supplied criteria. The argument is typically a string -identifying the basis of a sort (example: \code{'time'} or -\code{'name'}). - -When more than one key is provided, then additional keys are used as -secondary criteria when the there is equality in all keys selected -before them. For example, \samp{sort_stats('name', 'file')} will sort -all the entries according to their function name, and resolve all ties -(identical function names) by sorting by file name. - -Abbreviations can be used for any key names, as long as the -abbreviation is unambiguous. The following are the keys currently -defined: - -\begin{tableii}{l|l}{code}{Valid Arg}{Meaning} - \lineii{'calls'}{call count} - \lineii{'cumulative'}{cumulative time} - \lineii{'file'}{file name} - \lineii{'module'}{file name} - \lineii{'pcalls'}{primitive call count} - \lineii{'line'}{line number} - \lineii{'name'}{function name} - \lineii{'nfl'}{name/file/line} - \lineii{'stdname'}{standard name} - \lineii{'time'}{internal time} -\end{tableii} - -Note that all sorts on statistics are in descending order (placing -most time consuming items first), where as name, file, and line number -searches are in ascending order (i.e., alphabetical). The subtle -distinction between \code{'nfl'} and \code{'stdname'} is that the -standard name is a sort of the name as printed, which means that the -embedded line numbers get compared in an odd way. For example, lines -3, 20, and 40 would (if the file names were the same) appear in the -string order 20, 3 and 40. In contrast, \code{'nfl'} does a numeric -compare of the line numbers. In fact, \code{sort_stats('nfl')} is the -same as \code{sort_stats('name', 'file', 'line')}. - -For compatibility with the old profiler, the numeric arguments -\code{-1}, \code{0}, \code{1}, and \code{2} are permitted. They are -interpreted as \code{'stdname'}, \code{'calls'}, \code{'time'}, and -\code{'cumulative'} respectively. If this old style format (numeric) -is used, only one sort key (the numeric key) will be used, and -additional arguments will be silently ignored. -\end{methoddesc} - - -\begin{methoddesc}{reverse_order}{} -This method for the \class{Stats} class reverses the ordering of the basic -list within the object. This method is provided primarily for -compatibility with the old profiler. Its utility is questionable -now that ascending vs descending order is properly selected based on -the sort key of choice. -\end{methoddesc} - -\begin{methoddesc}{print_stats}{restriction\optional{, ...}} -This method for the \class{Stats} class prints out a report as described -in the \function{profile.run()} definition. - -The order of the printing is based on the last \method{sort_stats()} -operation done on the object (subject to caveats in \method{add()} and -\method{strip_dirs()}. - -The arguments provided (if any) can be used to limit the list down to -the significant entries. Initially, the list is taken to be the -complete set of profiled functions. Each restriction is either an -integer (to select a count of lines), or a decimal fraction between -0.0 and 1.0 inclusive (to select a percentage of lines), or a regular -expression (to pattern match the standard name that is printed; as of -Python 1.5b1, this uses the Perl-style regular expression syntax -defined by the \module{re} module). If several restrictions are -provided, then they are applied sequentially. For example: - -\begin{verbatim} -print_stats(.1, 'foo:') -\end{verbatim} - -would first limit the printing to first 10\% of list, and then only -print functions that were part of filename \samp{.*foo:}. In -contrast, the command: - -\begin{verbatim} -print_stats('foo:', .1) -\end{verbatim} - -would limit the list to all functions having file names \samp{.*foo:}, -and then proceed to only print the first 10\% of them. -\end{methoddesc} - - -\begin{methoddesc}{print_callers}{restrictions\optional{, ...}} -This method for the \class{Stats} class prints a list of all functions -that called each function in the profiled database. The ordering is -identical to that provided by \method{print_stats()}, and the definition -of the restricting argument is also identical. For convenience, a -number is shown in parentheses after each caller to show how many -times this specific call was made. A second non-parenthesized number -is the cumulative time spent in the function at the right. -\end{methoddesc} - -\begin{methoddesc}{print_callees}{restrictions\optional{, ...}} -This method for the \class{Stats} class prints a list of all function -that were called by the indicated function. Aside from this reversal -of direction of calls (re: called vs was called by), the arguments and -ordering are identical to the \method{print_callers()} method. -\end{methoddesc} - -\begin{methoddesc}{ignore}{} -\deprecated{1.5.1}{This is not needed in modern versions of Python.% -\footnote{ -This was once necessary, when Python would print any unused expression -result that was not \code{None}. The method is still defined for -backward compatibility. -}} -\end{methoddesc} - - -\section{Limitations} - -There are two fundamental limitations on this profiler. The first is -that it relies on the Python interpreter to dispatch \dfn{call}, -\dfn{return}, and \dfn{exception} events. Compiled \C{} code does not -get interpreted, and hence is ``invisible'' to the profiler. All time -spent in \C{} code (including built-in functions) will be charged to the -Python function that invoked the \C{} code. If the \C{} code calls out -to some native Python code, then those calls will be profiled -properly. - -The second limitation has to do with accuracy of timing information. -There is a fundamental problem with deterministic profilers involving -accuracy. The most obvious restriction is that the underlying ``clock'' -is only ticking at a rate (typically) of about .001 seconds. Hence no -measurements will be more accurate that that underlying clock. If -enough measurements are taken, then the ``error'' will tend to average -out. Unfortunately, removing this first error induces a second source -of error... - -The second problem is that it ``takes a while'' from when an event is -dispatched until the profiler's call to get the time actually -\emph{gets} the state of the clock. Similarly, there is a certain lag -when exiting the profiler event handler from the time that the clock's -value was obtained (and then squirreled away), until the user's code -is once again executing. As a result, functions that are called many -times, or call many functions, will typically accumulate this error. -The error that accumulates in this fashion is typically less than the -accuracy of the clock (i.e., less than one clock tick), but it -\emph{can} accumulate and become very significant. This profiler -provides a means of calibrating itself for a given platform so that -this error can be probabilistically (i.e., on the average) removed. -After the profiler is calibrated, it will be more accurate (in a least -square sense), but it will sometimes produce negative numbers (when -call counts are exceptionally low, and the gods of probability work -against you :-). ) Do \emph{NOT} be alarmed by negative numbers in -the profile. They should \emph{only} appear if you have calibrated -your profiler, and the results are actually better than without -calibration. - - -\section{Calibration} - -The profiler class has a hard coded constant that is added to each -event handling time to compensate for the overhead of calling the time -function, and socking away the results. The following procedure can -be used to obtain this constant for a given platform (see discussion -in section Limitations above). - -\begin{verbatim} -import profile -pr = profile.Profile() -print pr.calibrate(100) -print pr.calibrate(100) -print pr.calibrate(100) -\end{verbatim} - -The argument to \method{calibrate()} is the number of times to try to -do the sample calls to get the CPU times. If your computer is -\emph{very} fast, you might have to do: - -\begin{verbatim} -pr.calibrate(1000) -\end{verbatim} - -or even: - -\begin{verbatim} -pr.calibrate(10000) -\end{verbatim} - -The object of this exercise is to get a fairly consistent result. -When you have a consistent answer, you are ready to use that number in -the source code. For a Sun Sparcstation 1000 running Solaris 2.3, the -magical number is about .00053. If you have a choice, you are better -off with a smaller constant, and your results will ``less often'' show -up as negative in profile statistics. - -The following shows how the trace_dispatch() method in the Profile -class should be modified to install the calibration constant on a Sun -Sparcstation 1000: - -\begin{verbatim} -def trace_dispatch(self, frame, event, arg): - t = self.timer() - t = t[0] + t[1] - self.t - .00053 # Calibration constant - - if self.dispatch[event](frame,t): - t = self.timer() - self.t = t[0] + t[1] - else: - r = self.timer() - self.t = r[0] + r[1] - t # put back unrecorded delta - return -\end{verbatim} - -Note that if there is no calibration constant, then the line -containing the callibration constant should simply say: - -\begin{verbatim} -t = t[0] + t[1] - self.t # no calibration constant -\end{verbatim} - -You can also achieve the same results using a derived class (and the -profiler will actually run equally fast!!), but the above method is -the simplest to use. I could have made the profiler ``self -calibrating'', but it would have made the initialization of the -profiler class slower, and would have required some \emph{very} fancy -coding, or else the use of a variable where the constant \samp{.00053} -was placed in the code shown. This is a \strong{VERY} critical -performance section, and there is no reason to use a variable lookup -at this point, when a constant can be used. - - -\section{Extensions --- Deriving Better Profilers} -\nodename{Profiler Extensions} - -The \class{Profile} class of module \module{profile} was written so that -derived classes could be developed to extend the profiler. Rather -than describing all the details of such an effort, I'll just present -the following two examples of derived classes that can be used to do -profiling. If the reader is an avid Python programmer, then it should -be possible to use these as a model and create similar (and perchance -better) profile classes. - -If all you want to do is change how the timer is called, or which -timer function is used, then the basic class has an option for that in -the constructor for the class. Consider passing the name of a -function to call into the constructor: - -\begin{verbatim} -pr = profile.Profile(your_time_func) -\end{verbatim} - -The resulting profiler will call \code{your_time_func()} instead of -\function{os.times()}. The function should return either a single number -or a list of numbers (like what \function{os.times()} returns). If the -function returns a single time number, or the list of returned numbers -has length 2, then you will get an especially fast version of the -dispatch routine. - -Be warned that you \emph{should} calibrate the profiler class for the -timer function that you choose. For most machines, a timer that -returns a lone integer value will provide the best results in terms of -low overhead during profiling. (\function{os.times()} is -\emph{pretty} bad, 'cause it returns a tuple of floating point values, -so all arithmetic is floating point in the profiler!). If you want to -substitute a better timer in the cleanest fashion, you should derive a -class, and simply put in the replacement dispatch method that better -handles your timer call, along with the appropriate calibration -constant :-). - - -\subsection{OldProfile Class} - -The following derived profiler simulates the old style profiler, -providing errant results on recursive functions. The reason for the -usefulness of this profiler is that it runs faster (i.e., less -overhead) than the old profiler. It still creates all the caller -stats, and is quite useful when there is \emph{no} recursion in the -user's code. It is also a lot more accurate than the old profiler, as -it does not charge all its overhead time to the user's code. - -\begin{verbatim} -class OldProfile(Profile): - - def trace_dispatch_exception(self, frame, t): - rt, rtt, rct, rfn, rframe, rcur = self.cur - if rcur and not rframe is frame: - return self.trace_dispatch_return(rframe, t) - return 0 - - def trace_dispatch_call(self, frame, t): - fn = `frame.f_code` - - self.cur = (t, 0, 0, fn, frame, self.cur) - if self.timings.has_key(fn): - tt, ct, callers = self.timings[fn] - self.timings[fn] = tt, ct, callers - else: - self.timings[fn] = 0, 0, {} - return 1 - - def trace_dispatch_return(self, frame, t): - rt, rtt, rct, rfn, frame, rcur = self.cur - rtt = rtt + t - sft = rtt + rct - - pt, ptt, pct, pfn, pframe, pcur = rcur - self.cur = pt, ptt+rt, pct+sft, pfn, pframe, pcur - - tt, ct, callers = self.timings[rfn] - if callers.has_key(pfn): - callers[pfn] = callers[pfn] + 1 - else: - callers[pfn] = 1 - self.timings[rfn] = tt+rtt, ct + sft, callers - - return 1 - - - def snapshot_stats(self): - self.stats = {} - for func in self.timings.keys(): - tt, ct, callers = self.timings[func] - nor_func = self.func_normalize(func) - nor_callers = {} - nc = 0 - for func_caller in callers.keys(): - nor_callers[self.func_normalize(func_caller)] = \ - callers[func_caller] - nc = nc + callers[func_caller] - self.stats[nor_func] = nc, nc, tt, ct, nor_callers -\end{verbatim} - -\subsection{HotProfile Class} - -This profiler is the fastest derived profile example. It does not -calculate caller-callee relationships, and does not calculate -cumulative time under a function. It only calculates time spent in a -function, so it runs very quickly (re: very low overhead). In truth, -the basic profiler is so fast, that is probably not worth the savings -to give up the data, but this class still provides a nice example. - -\begin{verbatim} -class HotProfile(Profile): - - def trace_dispatch_exception(self, frame, t): - rt, rtt, rfn, rframe, rcur = self.cur - if rcur and not rframe is frame: - return self.trace_dispatch_return(rframe, t) - return 0 - - def trace_dispatch_call(self, frame, t): - self.cur = (t, 0, frame, self.cur) - return 1 - - def trace_dispatch_return(self, frame, t): - rt, rtt, frame, rcur = self.cur - - rfn = `frame.f_code` - - pt, ptt, pframe, pcur = rcur - self.cur = pt, ptt+rt, pframe, pcur - - if self.timings.has_key(rfn): - nc, tt = self.timings[rfn] - self.timings[rfn] = nc + 1, rt + rtt + tt - else: - self.timings[rfn] = 1, rt + rtt - - return 1 - - - def snapshot_stats(self): - self.stats = {} - for func in self.timings.keys(): - nc, tt = self.timings[func] - nor_func = self.func_normalize(func) - self.stats[nor_func] = nc, nc, tt, 0, {} -\end{verbatim} |