Re: Speed suggestions (previously about laptop performace)

[Soeren Sandmann <sandmann daimi au dk>]

Michael Meeks <michael ximian com> writes:

> 	I also have patches, pending Kris' return to do itimer profiling using
> the same engine, a fusion of 'eazel-tools/prof' and 'memprof', which is
> rather nice [ although symbol problems, ie. it often lies about the
> methods taking the time, make it less effective ].

The way Eazel's profiler works is that is that it installs an itimer
and then generates a stack trace in the signal handler. The stack
trace is generated either by glibc's backtrace() or by taking the
address of a parameter and tracing from there.

One problem with both methods is that the top of the stack is not a
normal frame when you are inside a signal handler. To work around
this, I believe Eazel's profiler just ignores the top frame, which
means that the traces it generates start from the second frame, which
means that leaf procedures are never accounted for. This could account
for the lying.

The way to generate a stack trace from inside a signal handler is
like this (obviously platform dependent - this is for linux/x86):

#include <sys/time.h>
#include <signal.h>

typedef struct Frame Frame;
struct Frame {
    Frame *prev;
    void *caller;
};

enum { N_FRAMES = 512 };

static void
signal_handler (int signum)
{
    struct Frame *frame;
    struct sigcontext_struct *ctxt;
    void *trace[N_FRAMES];
    int i;

    ctxt = (&signum + 1);

    trace[0] = ctxt->eip;

    i = 1;
    for (frame = ((Frame *)(&signum - 2))->prev; frame; frame = frame->prev)
	trace[i++] = frame->caller;

    /* now trace[] contains a stack trace with i entries */
}

(This is adapted from some other code and not tested in the above
form)