This shows that of the 151603 times the timer fired, 1777 (1.2% of the total) were inside nsStyleContext::GetStyleData() and 1552 (1.0% of the total) were in the nsCOMPtr_base destructor.
<p>
In general, the functions with the highest count are the functions which
are taking the most time.
<P>
The function names are linked to the entry for that function in the
hierarchical profile, which is described in the next section.
<h4><aname="hier">Hierarchical output</a></h4>
The hierarchical output is divided up into sections, with each section
corresponding to one function. A typical section looks something like
<li>There were 0 profiler hits <em>in</em><code>PL_HandleEvent</code>
<li>There were 142227 profiler hits <em>under</em><code>PL_HandleEvent</code>. Of these:
<ul>
<li>92394 were in or under <code>nsInputStreamReadyEvent::EventHandler</code>
<li>49181 were in or under <code>HandlePLEvent(ReflowEvent*)</code>
<li>481 were in or under <code>handleTimerEvent</code>
<li>158 were in or under <code>nsTransportStatusEvent::HandleEvent</code>
<li>9 were in or under <code>PL_DestroyEvent</code>
<li>4 were in or under <code>__restore_rt</code>
</ul>
<li>Of these 142227 calls into <code>PL_HandleEvent</code>:
<ul>
<li>141300 came from <code>PL_ProcessPendingEvents</code>
<li>927 came from <code>PL_ProcessEventsBeforeID</code>
</ul>
</ul>
The rest of this section explains how to read this information off from the jprof output.
<p>This block corresponds to the function <code>PL_HandleEvent</code>, which is
therefore bolded and not a link. The name of this function is preceded by
three numbers which have the following meaning. The number on the left (29358)
is the index number, and is not important. The center number (0) is the number
of times this function was interrupted by the timer. The last number (142227)
is the number of times this function was in the call stack when the timer went
off. That is, the timer went off while we were in code that was ultimately
called from <code>PL_HandleEvent</code>.
<p>For our example we can see that our function was in the call stack for
142227 interrupt ticks, but we were never the function that was running when
the interrupt arrived.
<P>
The functions listed above the line for <code>PL_HandleEvent</code> are its
callers. The numbers to the left of these function names are the numbers of
times these functions were in the call stack as callers of
<code>PL_HandleEvent</code>. In our example, we were called 927 times by
<code>PL_ProcessEventsBeforeID</code> and 141300 times by
<code>PL_ProcessPendingEvents</code>.
<P>
The functions listed below the line for <code>PL_HandleEvent</code> are its
callees. The numbers to the left of the function names are the numbers of
times these functions were in the callstack as callees of <code>PL_HandleEvent</code>. In our example, of the 142227 profiler hits under <code>PL_HandleEvent</code> 92394 were under <code>nsInputStreamReadyEvent::EventHandler</code>, 49181 were under <code>HandlePLEvent(ReflowEvent*)</code>, and so forth.
<h3>Bugs</h3>
Jprof has only been tested under Red Hat Linux 6.0, 6.1, and 6.2. It does
not work under 6.0, though it is possible hack up the source code and make
it work there. The way I determine the stack trace from inside the
signal handler is tightly bound to the version of glibc that is running.
If you know of a more portable way to get this information please let
me know.
<h3>Update</h3>
<ul>
<li>Ben Bucksch reports that installing the Red Hat 6.1 glibc rpms on a Red Hat
6.0 system allows jprof to work, and does not seem to break anything except
gdm (the Gnome login program), and that can be fixed by installing the RH 6.1
gdb rpm.</li>
<li>David Baron reports that jprof works under RedHat 6.0 if one uncomments
the <code>#define JPROF_PTHREAD_HACK</code> near the beginning of
