MOO-cows Mailing List Archive


RE: profiling


From:  ThwartedEfforts[]
Sent:  Thursday, August 01, 1996 8:44 AM
To:  Erik Ostrom
Cc:  moo-cows
Subject:  Re: profiling

<snip some paragraphs...>

>  * 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   
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   
level, with a new statement, then leaves it up to the programmer to   
their profiling data however they see fit (another idea would be add a   
flag to verbs to turn profiling on for that verb, and have the server   
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).   

<snip again>



I'll prefered to *not* see another properties on verb who can became as
useless than -d (although some people can use it somewhere :).
Why not just set an compile option in the in-db verb editor? This option
will strip the profile code (and why not some debug features like ones
I try to put on my private db) when you don't need it. This can be done
too in server by program() but I think that's can be done easily in db
so why put it in server.

Almost, I really like this implementation of the profiler and, like Andy   
keep it simple and let's to users the choice of interface. program()   
a pretty interface but check about @program (or @edit verb) and you see
what users can do with so >little<*

* my purpose here is not to say that program() aren't good! It just do   
what he
has to do, nothing more and that's perfect!

contradiction is not that free software are among the best,
   it's that   
commercial software aren't the best of   
en Ninoles aka the Baggus Mage aka Baffouille   
          finger me for my PGP Public   

Home | Subject Index | Thread Index