Re: profiling

• Date: Thu, 1 Aug 1996 08:44:18 PDT
• From:
  ThwartedEfforts <abakun@scinc.com>
• Cc: moo-cows@parc.xerox.com
• Content-Type: text/plain; charset="us-ascii"

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.

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