# profiling

ThwartedEfforts (abakun@scinc.com)
Thu, 1 Aug 1996 08:44:18 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    At 07:37 AM 8/1/96 PDT, Erik Ostrom <eostrom@research.att.com> wrote:

    <snip>
    >Note that any programmer could do this for eir own code.

    This is where being able to profile comes in really handy.  We could then
    get on people to make their code better.  "No excuses, the tools exist!"

    >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.

    Does this pick up profiling data for tasks that are currently suspended and
    in the middle of their code, or just tasks that start anew (command tasks or
    forks)?
    I don't know what the structure is of your profiling value so I can't say if
    it would be wise to only do new tasks rather than including all.  Is the
    structure of the list long?  Can you send it under separate cover?

    >  * Do we need a programmer-level profiling facility?

    Yes.  Otherwise, the ability to profile code would fall into disuse and
    people would be unfamilar with it.   There are many more

    >  * Do we need a global profiling facility?

    Yes.  You cann't learn anything about the operation of the system as a whole
    unless you can step back and look at it globally.  While, yes, you could
    wrap an entire execution cycle in the profile statement, this would not
    necessilary show you how many times, for example, that a certain verb is
    being called by all tasks.

    >  * Is it appropriate to use a statement for profiling?
    >  * (What are other alternatives?)

    Over what?  A series of builtin functions?  Either way, the code has to be
    edited to remove the profiling specific stuff once the code becomes
    production.  I don't think this should be an issue.  By doing it on the code
    level, with a new statement, then leaves it up to the programmer to handle
    their profiling data however they see fit (another idea would be add a new
    flag to verbs to turn profiling on for that verb, and have the server store
    the data in some prop on the object that contains the verb, but this is a
    bad idea, for the whole 'server assumptions about the database' problem).

    >  * What, if anything, should be done about forked tasks?

    Nothing.  Since the variable that will be assigned to for the profile
    statement will not exist UNTIL the endprofile is reached, then forked tasks
    couldn't see it anyway (also taking into account normal scoping rules).  The
    only way to get profiling data for forked tasks should be actually profile
    them, by including a profile statement within the fork.  MOO forked tasks
    only inherit the currently defined variable from their creating task, why
    should they inherit profiling?

    >  * Are lists of lists a good format?
    >  * (What are other alternatives?)

    Easiest to handle, I think.  As long as the strucuture is simple and
    somewhat follows the "standard" in use by things like
    $handle_uncaught_error, $handle_task_timeout, queued_tasks(), etc, it
    shouldn't be a problem.

    >  * 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.)

    The user interface should be the profiling data assigned to the profiling
    variable.  Keeping it simple will allow any number of interfaces to spring
    up, but I'm sure everyone already knew that.  I'd rather get too much data
    for my user interface implementation rather than too little.

    Andy.