Re: profiling

• Date: Fri, 2 Aug 1996 12:39:47 PDT
• From:
  Erik Ostrom <eostrom@research.att.com>
• 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.

• Re: profiling
• From: <thomas@xs4all.nl>

• Re: profiling
• From: Amy Bruckman <asb@media.mit.edu>

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