Robert Muil <
r.muil@crcmining.com.au> wrote:
I don't know about Visual Studio. I do know that gprof lies. (Well, it
makes naive assumptions and reports them as fact.)
Consider:
expensive_func( int COUNT )
{
/* do something time consuming COUNT times */
}
funca() { expensive_func( 10 ); }
funcb() { expensive_func( 1000 ); }
int main() {
while(1) {
funca();
funcb();
}
}
I cannot get stats for this, with gprof. I compile it with 'cc -g -p
main.c', then run it with ./a.out to generate the gmon.out. When I run
gprof, it tells me the call counts, but contains no times at all.
Wasn't intended to be a compilable example -- I'll include at the end
the actual sample code I used, and the gprof output.
The relevant bits are:
-----------------------------------------------
0.00 0.47 23/23 main [1]
[5] 50.7 0.00 0.47 23 afunc [5]
0.01 0.46 23/45 dofuncs [3]
-----------------------------------------------
0.00 0.45 22/22 main [1]
[6] 48.6 0.00 0.45 22 bfunc [6]
0.01 0.44 22/45 dofuncs [3]
Note that the CPU% attributed to afunc vs bfunc is, basically,
the number of times they've called dofuncs, over total times
dofuncs() is called. (23/45 = 51.1%, 22/45 = 48.9%).
Also, to get time data, you need to run the program as root --
the profiling code attaches an interrupt handler to the timer
interrupt to get the sampling data, if it can't attach the
interrupt, all it can get is the call count.
Yes, and we work to fix bugs in the Eclipse core, and to get features
or extensions we want/need into the core.
I think the editiability of functions outside the workspace is supposed
to be much better with the next generation of the core Eclipse tools.
That's good to hear. Will this be available for 6.2.1 or just >6.3.0?
I think it is added to the core with Eclipse 3.0. It will definitely
be post 6.3.0.
Also, I have read all that documentation, and it is not very helpful.
And, the update tools is one that is not needed for useage as a QNX
development environment -- unless you're adding someone else's tools
to the IDE. We try to enhance documentation as needed for core pieces
that are used for QNX development, as well as documenting the non-core
pieces that are QNX specific.
I appreciate that people like yourself do, and QNX's development is
admirable. But please, less marketing hype. Aim the documentation at
technicians and engineers, not other marketing departments.
Wish I could control the marketing hype. But, apparently, the marketing
people think that generating hype is their job.
I can add a huge list of other complaints, at the top of which would be:
+ my workbench layou is "failed to load" almost every time I run the IDE
Does it generate a .log file when it fails? Check in workspace/.metadata
for a file called ".log". Each time the IDE has an error, it is supposed
to generate a log to that file. Posting the .log file with a description
of the error may allow the problem to be resolved.
I have looked through this log and am none the wiser, but I will post it
when the error occurs again (the whole log file is formidably large atm).
You don't generally need to post the whole log -- each entry (which
is multiple lines long) is dated at the start of the entry. Also,
if the IDE is not running, you can just delete the .log file, to start
from a clean log.
(Each entry in the log will start with the key string "!ENTRY".)
+ javaw.exe locks on 100% CPU nearly every 2nd time I run the IDE
Can you describe what you do to trigger this fault?
So far, the only common trigger is running the IDE. It is usually associated
with a debugging or system information session, but it is intermittent.
Is it also associated with a loss of connectivity to the client? Either
through client restart, qconn crash, or other such thing? If debugging,
do you find a nto_gdb* process running using lots of CPU? If so, does
killing that process off help recover?
-David
Flat profile:
Each sample counts as 0.001 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
68.06 0.63 0.63 44 14386.36 14386.36 func2
29.46 0.91 0.27 45 6088.89 6088.89 func1
1.61 0.92 0.01 45 333.33 20488.89 dofuncs
0.75 0.93 0.01 1 7000.00 930000.00 main
0.11 0.93 0.00 22 45.45 20534.34 bfunc
0.00 0.93 0.00 23 0.00 20488.89 afunc
0.00 0.93 0.00 1 0.00 0.00 options
% the percentage of the total running time of the
time program used by this function.
cumulative a running sum of the number of seconds accounted
seconds for by this function and those listed above it.
self the number of seconds accounted for by this
seconds function alone. This is the major sort for this
listing.
calls the number of times this function was invoked, if
this function is profiled, else blank.
self the average number of milliseconds spent in this
ms/call function per call, if this function is profiled,
else blank.
total the average number of milliseconds spent in this
ms/call function and its descendents per call, if this
function is profiled, else blank.
name the name of the function. This is the minor sort
for this listing. The index shows the location of
the function in the gprof listing. If the index is
in parenthesis it shows where it would appear in
the gprof listing if it were to be printed.
Call graph (explanation follows)
granularity: each sample hit covers 4 byte(s) for 0.11% of 0.93 seconds
index % time self children called name
0.01 0.92 1/1 _start [2]
[1] 100.0 0.01 0.92 1 main [1]
0.00 0.47 23/23 afunc [5]
0.00 0.45 22/22 bfunc [6]
0.00 0.00 1/1 options [8]
-----------------------------------------------
<spontaneous>
[2] 100.0 0.00 0.93 _start [2]
0.01 0.92 1/1 main [1]
-----------------------------------------------
0.01 0.44 22/45 bfunc [6]
0.01 0.46 23/45 afunc [5]
[3] 99.1 0.01 0.91 45 dofuncs [3]
0.63 0.00 44/44 func2 [4]
0.27 0.00 45/45 func1 [7]
-----------------------------------------------
0.63 0.00 44/44 dofuncs [3]
[4] 68.1 0.63 0.00 44 func2 [4]
-----------------------------------------------
0.00 0.47 23/23 main [1]
[5] 50.7 0.00 0.47 23 afunc [5]
0.01 0.46 23/45 dofuncs [3]
-----------------------------------------------
0.00 0.45 22/22 main [1]
[6] 48.6 0.00 0.45 22 bfunc [6]
0.01 0.44 22/45 dofuncs [3]
-----------------------------------------------
0.27 0.00 45/45 dofuncs [3]
[7] 29.5 0.27 0.00 45 func1 [7]
-----------------------------------------------
0.00 0.00 1/1 main [1]
[8] 0.0 0.00 0.00 1 options [8]
-----------------------------------------------
This table describes the call tree of the program, and was sorted by
the total amount of time spent in each function and its children.
Each entry in this table consists of several lines. The line with the
index number at the left hand margin lists the current function.
The lines above it list the functions that called this function,
and the lines below it list the functions this one called.
This line lists:
index A unique number given to each element of the table.
Index numbers are sorted numerically.
The index number is printed next to every function name so
it is easier to look up where the function in the table.
% time This is the percentage of the `total' time that was spent
in this function and its children. Note that due to
different viewpoints, functions excluded by options, etc,
these numbers will NOT add up to 100%.
self This is the total amount of time spent in this function.
children This is the total amount of time propagated into this
function by its children.
called This is the number of times the function was called.
If the function called itself recursively, the number
only includes non-recursive calls, and is followed by
a `+' and the number of recursive calls.
name The name of the current function. The index number is
printed after it. If the function is a member of a
cycle, the cycle number is printed between the
function's name and the index number.
For the function's parents, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the function into this parent.
children This is the amount of time that was propagated from
the function's children into this parent.
called This is the number of times this parent called the
function `/' the total number of times the function
was called. Recursive calls to the function are not
included in the number after the `/'.
name This is the name of the parent. The parent's index
number is printed after it. If the parent is a
member of a cycle, the cycle number is printed between
the name and the index number.
If the parents of the function cannot be determined, the word
`<spontaneous>' is printed in the `name' field, and all the other
fields are blank.
For the function's children, the fields have the following meanings:
self This is the amount of time that was propagated directly
from the child into the function.
children This is the amount of time that was propagated from the
child's children to the function.
called This is the number of times the function called
this child `/' the total number of times the child
was called. Recursive calls by the child are not
listed in the number after the `/'.
name This is the name of the child. The child's index
number is printed after it. If the child is a
member of a cycle, the cycle number is printed
between the name and the index number.
If there are any cycles (circles) in the call graph, there is an
entry for the cycle-as-a-whole. This entry shows who called the
cycle (as parents) and the members of the cycle (as children.)
The `+' recursive calls entry shows the number of function calls that
were internal to the cycle, and the calls entry for each member shows,
for that member, how many times it was called from other members of
the cycle.
Index by function name
[5] afunc [7] func1 [8] options
[6] bfunc [4] func2
[3] dofuncs [1] main
/*
* appprofile_looper
*
* This is a sample for demonstrating the use of the application profiler
* tool. It is a very phoney but effective sample (i.e. it does nothing
* practical but is useful for demonstrating profiling).
*
* If you run it with no command line arguments then it will loop forever.
* On SIGINT or SIGTERM it will exit and write a gmon.out file.
*
*
*/
#include <stdlib.h>
#include <stdio.h>
#include <inttypes.h>
#include <sched.h>
#include <unistd.h>
#include <pthread.h>
void *other_thread (void *arg);
void dofuncs (uint64_t count);
uint64_t func1 (uint64_t n);
uint64_t func2 (uint64_t n);
void options (int argc, char **argv);
int loop_once; /* -o to have it loop only once */
int optv; /* -v for verbose operation */
char *progname;
int tid;
void sig_exit( int signo )
{
pthread_cancel(tid );
printf("exit from sig exit\n");
exit(EXIT_SUCCESS );
}
void afunc()
{
dofuncs (1000000);
}
void bfunc()
{
dofuncs (100000);
}
int
main (int argc, char *argv[])
{
progname = argv[0];
setvbuf(stdout, NULL, _IOLBF, BUFSIZ );
printf ("%s: starting...\n", progname);
options (argc, argv);
signal( SIGTERM, sig_exit );
signal( SIGINT, sig_exit );
setprio (0, 5); /* run at low priority, 5, so we don't hog CPU */
//pthread_create (&tid, NULL, other_thread, NULL);
while (1) {
afunc();
bfunc();
}
printf ("%s: exiting...\n", progname);
return EXIT_SUCCESS;
}
void *
other_thread (void *arg)
{
while (1) {
dofuncs (100000);
if (loop_once)
break;
delay (1); /* put a minimal delay so that this thread will run less */
}
return NULL;
}
void
dofuncs (uint64_t count) /* dofuncs() is an excuse to have more call layers */
{
//uint64_t count = 1000000; /* larger is better */
func1 (count);
func2 (count);
}
uint64_t
func1 (uint64_t n) /* 33.3% of total run time */
{
volatile uint64_t a, b, c;
if (optv)
printf ("%s: Now in func1()\n", progname);
for (a = 0; a < 2*n; a++) {} /* 50% of func1() time */
for (b = 0; b < n; b++) {} /* 25% of func1() time */
for (c = 0; c < n; c++) {} /* 25% of func1() time */
return 1;
}
uint64_t
func2 (uint64_t n) /* 66.7% of total run time */
{
volatile uint64_t d, e;
if (optv)
printf ("%s: Now in func2()\n", progname);
for (d = 0; d < n; d++) {} /* 12.5% of func2() time */
for (e = 0; e < 7*n; e++) {} /* 87.5% of func2() time */
return 1;
}
/*
* options
*
* This routine handles the command line options.
* We support:
* -o loop only once
* -v verbose operation
*/
void
options (int argc, char **argv)
{
int opt;
optv = 0;
loop_once = 0;
while ((opt = getopt (argc, argv, "ov")) != -1) {
switch (opt) {
case 'o':
loop_once = 1;
break;
case 'v':
optv = 1;
break;
}
}
}
--
David Gibbs
QNX Training Services
dagibbs@qnx.com
