profile stats interpretation

[Robert Brewer]

Peter Otten wrote:
> Instead of
> 
> >             valuetype = type(value)
> 
>               valuetype =  value.__class__
> 
> might work, too.

Thanks! timeit says that's about %40 faster. I'll run it through the
test suite.

> >         try:
> >             xform = self.processors[valuetype]
> >         except KeyError:
> >             xform = self.default_processor
> 
>               # assuming the normal type/value ratio the following
>               # line could drastically increase your hit rate.
>               self.processors[valuetype] = xform

<:) I should have thought of that one. Now that I've hammered out the
use cases (I know the limited set of types I should support), I could
probably get rid of default_processor (and try: block) completely.

> Once you have spotted a single slow function in heavy usage 
> you can resort
> to a micro-optimization tool like timeit. A function is 
> "slow" when your
> app spends a long time in it and the subroutine calls are 
> necessary and
> cannot be optimized themselves. Then picking the variant with 
> the smallest
> cumulated time should be a no-brainer.

Right. Mostly? Might the cumtime include I/O, IPC and other processes
whose times are unreliable?

And have I mentioned lately that I love Python? :) Three lines of
hotshot code dropped into the CGI request processor has gotten me a long
way in the last couple of days. I found a particularly slow routine
where I was calling the database 15 times more than I needed to... >:(

Thanks for the comments!


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org