guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: May nearly have simple statistical profiler working (need help).


From: Neil Jerram
Subject: Re: May nearly have simple statistical profiler working (need help).
Date: 14 Jul 2001 23:19:41 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Rob" == Rob Browning <address@hidden> writes:

    Rob> I think I nearly have a (very) simple version working, but
    Rob> I'm getting some unexpected results, and I wanted to see if
    Rob> others could help make sure I understand some of the less
    Rob> well documented bits I needed to use.

I hope to have a closer look at your code soon; in the meanwhile I'll
try to answer some of your questions...

    Rob> So what is the difference between apply-frame and
    Rob> enter-frame, and is the apply-frame handler guaranteed to be
    Rob> run for *every* function that's called?  Is apply-frame
    Rob> sufficient to catch all calls?

As far as I understand, yes.  Can you demonstrate a case where this
appears to be untrue?

    Rob> Further, can someone tell me what's normally on the stack?
    Rob> i.e. when you (make-stack #t), you get a set of frames, but
    Rob> what exactly is a frame -- what in the source causes one to
    Rob> be created?

I think that a frame is either an evaluation or an application.
Hmmm... but perhaps when an evaluation expression consists only of an
application, the evaluation frame gets overwritten by the application
frame, so that you don't see effectively the same frame twice in the
stack.

Tail recursive frames overwrite the last frame as well; so perhaps the
mechanism is similar.

Evaluation frames that describe syntactic forms (if, let, ...) are
visible in the stack, so I guess they don't get overwritten.

I think that the source code that creates a frame is mostly (and
confusingly) the PREP_APPLY macro in eval.c, specifically
`++debug.info'.

    Rob>              More directly, if I scan for all frames have a
    Rob> non-false frame-procedure? result, will I hit all the frames
    Rob> that contain procedures, primitive-procedures, etc. -- all
    Rob> the stuff you'd normally want to profile?

    Rob> Also, does masking signals just block them briefly, or could
    Rob> they be dropped (I don't mind if multiple signals are
    Rob> collapsed into one pending signal, I just don't want to miss
    Rob> a set of signals altogether).

Sorry, no idea about these last two. :-(

        Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]