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

# profiling

- Date: Thu, 1 Aug 1996 07:37:19 PDT
- From:

    Well, I've been silent another week, but rest assured, I _have_ been
    paying attention; it's been really interesting, not least because I've
    seen a good number of proposals that I hadn't seen before.  Rather
    than try to respond to each message individually, I'm going to try,
    over the next few days, to group the discussion into some common areas
    and give some thoughts on those.

    I think the feature that's been requested most and argued about the
    least is a MOO-code profiler--tools that would allow programmers to
    determine what parts of their code are slowing things down, what's
    called most, what would be good to optimize, and so on.  Some of you
    know that Pavel asked would-be server maintainers to write a profiler;
    a few of you know that I got a design and much of an implementation
    done, but not the whole thing.  Since there's demand and I have some
    grasp on the issues already, I'm likely to do this one.

    (People who aren't interested in profiling can safely stop reading here.)

    The main problem with my design was that it was made in a near-vacuum.
    I'd like to hear from the rest of you--and particularly those of you
    who really want a profiler--how you think it should work.  There are
    radically different ways to do it; I'd like to hear alternatives,
    although I reserve the final decision for myself.

    I'll start by throwing out my design, so people can point out the
    flaws and suggest improvements or complete rewrites.  Here's an
    excerpt from the documentation I wrote for the main profiling
    facility:

    ------------------------------------------------------------------------
    In order for programmers to write efficient code with reasonable effort,
    it is often useful to find out where the MOO virtual machine is spending
    most of its time in executing some application or utility.  This allows
    them to concentrate their efforts on code that is actually called often
    or noticeably expensive, rather than perhaps spending too much time on
    code sections that will have little effect on overall execution time.

    The /profile/ statement can be used to gather this data about
    execution cost.  It provides a listing of the verbs called in executing
    a particular sequence of statements, along with information about how
    many times they are used, how long each of them runs, and so on.  Its
    syntax is this:

        profile variable
          statements
        endprofile

    The /profile/ statement first executes the statements; the given
    variable is not assigned a value prior to or during their execution.
    After the statements are executed, the variable is assigned a value
    containing profiling data from the execution of the statements.  (Any
    tasks forked during their execution will not be profiled.)

    [ ... details about the format of profiling data deleted; suffice it
      to say it's a list of lists with information about each verb. ]

    Where execution enters a verb not readable by the programmer of the
    profile statement, no information is provided about the verbs it calls.
    (Otherwise, a programmer would be able to infer much of the contents of
    an unreadable verb just by calling it inside a profile statement.)
    Profiling data for the unreadable verb itself is still provided; the
    verb name used will be the name it is called with.

    After the profiled statements execute, the given variable is available
    and initially contains the profiling data -- even if the profiled
    statements exit by returning a value or raising an error.  In this
    way, the /profile/ statement is similar to the /try/ statement.
    However, /profile/ does *not* guarantee that code following it will be
    run; the /try/ statement must still be used if that is required.

    A typical method of profiling, then, would be to wrap a /profile/
    statement around a verb one wishes to gather data on, using a variable
    known not to be used in the verb; wrap a /try/ statement around
    that; and provide a /finally/ clause that will store the data in
    some useful place, so that data from multiple invocations under typical
    use can be examined later, summed and averaged.  The code for this might
    then look something like this:

        try
          profile profile_data
            this:go_about_my_usual_business();
          endprofile
        finally
          this.profile = {@this.profile_data, profile_data};
        endtry
    ------------------------------------------------------------------------

    The idea is that you could fairly easily write a verb `@profile
    object:verb', which would automatically wrap foo:bar's code in try/profile
    statements.  Note that any programmer could do this for eir own code.

    In addition, since a lot of the demand for profiling is (I think) from
    wizards who want to speed up their MUDs, there was to be a global
    profiling facility:

      x = global_profile(NUM n)

    /global_profile/ suspends for n seconds, then returns profiling data
    (in the same form as the /profile/ statement) for all the code
    executed during that time.

    So, things for people to react to, off the top of my head:

      * Do we need a programmer-level profiling facility?
      * Do we need a global profiling facility?
      * Is it appropriate to use a statement for profiling?
      * (What are other alternatives?)
      * What, if anything, should be done about forked tasks?
      * Are lists of lists a good format?
      * (What are other alternatives?)
      * What should the user interface to profiling be?  (I.e., is
        `@profile object:verb' sufficient?  I don't intend to write
        the in-db layers of profiling, but requirements for that
        may affect the design of the server facility.)
      * Did you have some totally different model in your head for
        how this would work?
      * Anything else?

    Comments, please.

    --Erik

Follow-Ups:

- Re: profiling

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

- Re: profiling

- From: Bill Drury <bild@io.com>

- Prev: Re: process size
- Next: re: profiling
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index