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

# Re: profiling

- Date: Fri, 2 Aug 1996 12:39:47 PDT
- From:
- cc: moo-cows@parc.xerox.com
- Content-Type: text/plain; charset=us-ascii
- In-reply-to: Your message of "Thu, 01 Aug 1996 08:50:46 PDT." <9608011550.AA12031@kilpikonna.media.mit.edu>

    Amy wrote:
    > Would it break down the output from other verbs called by this verb?
    > In my in-db parser, I'd really like to profile a call to do_command
    > and get the complete picture of where my ticks are going.  But where
    > the ticks are going may be several function calls deep.

    Yes; my plan was that you would get a summary of information from the
    call tree whose root is in the verb the profile statement is in--in your
    case, do_command, every verb it calls, every verb those call, and so on.
    (Unreadable verbs would be "black boxes", but if you're a wizard, that's
    not an issue.)

    > > (Any tasks forked during their execution will not be profiled.)
    >
    > Could this be an option?

    Not easily, in the design as proposed.  There are at least two factors
    working against it:

      * The whole _point_ of fork (arguably) is that it throws away the stack.
        Forked tasks never return to the context they were called from.
        The profile statement, in contrast, is decidedly stack-based--
        it monitors everything that happens "inside" the profile/endprofile
        block, and profiling data is available when and only when the
        endprofile is returned to.

      * Less subtly, there's the issue of whether the forked task's duration
        is contained within that of the calling task.  Consider the following
        code:

          profile my_profile_data
            fork (10)
              #0:do_something_really_complicated();
            endfork
          endprofile
          player:tell("Profiling data:  ", toliteral(my_profile_data));

        If forked tasks were to be monitored by the profiler, well, sure,
        we could keep track of what happened during the forked call to
        #0:do_something_really_complicated(); but, once we've collected
        all that data, where does it _go_?  The main verb has already
        gone through the endfork, endprofile, and reporting of data,
        ten seconds ago; how do we get the data from the forked task at
        this point?

    I can't think of any good solutions to this that I could implement
    immediately.  With some of the other server changes I'm thinking
    about, a better one might be possible.  Or, of course, it's quite
    plausible that there's a good solution available now that I'm just
    missing.  I'm hoping if there is one, it'll come from someone on
    moo-cows.

    The good news, by the way, is that neither of the two problems with
    forked tasks apply in any way to suspend(), so tasks that suspend
    can be profiled without difficulty.

Follow-Ups:

- Re: profiling

- From: <thomas@xs4all.nl>

References:

- Re: profiling

- From: Amy Bruckman <asb@media.mit.edu>

- Prev: Re: profiling
- Next: Re: profiling
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index