Concerns about performance w/Python, Pysco on Pentiums

[Pedro]

"Andrew Bennetts" <andrew-pythonlist at puzzling.org> wrote in message
news:mailman.1047024694.5760.python-list at python.org...
> On Fri, Mar 07, 2003 at 08:48:55AM +0100, Pedro Rodriguez wrote:
> > On Thu, 06 Mar 2003 20:35:14 +0100, Peter Hansen wrote:
> >
> > >     def step(self):
> > >         opcodeByte = self.readByte(self.PC)
> > >         try:
> > >             opcode = self.opcodes[opcodeByte]
> > >         except KeyError:
> > >             raise UnimplementedOpcode('$%02X %s' % (opcodeByte,
> > > self.readMemory(self.PC + 1, 5)))
> > >         else:
> > >             ...
> >
> > if you are using a dictionnary for opcodes, wouldn't you gain
> > time by not putting a try/except clause but by going straight
> > with self.opcodes.get(...) and checking the returned value
> > against None.
>
> Depends on how frequently the simulator attempts to lookup an non-existent
> opcode.  My guess is that it would only happen rarely, in which case
> try/except will be faster.
>
You're totally right, and replacing in my example the 'i' reference with '1'
(which always succeeds) proves your point (timing on windows this time) :
get 1.89100003242
try 0.84399998188

And getting ride of the try/except doesn't buy apparently much
(timed at approx 0.7, which is still some 20% gain). If the exception case
MUST never happen (except while debugging) and the frequency look up is
very high, it may be worth moving the try/except clause around the 'loop'
to catch some fatal errors.

I would even consider having checking that self.opcodes[...] return a
tuple containing (mode, length,...) instead of going through attribute
look up for opcode.xxx .

> As always, the only way to know for sure is to try it on the actual code
and
> time it :)
>
Yes.

> -Andrew.
>
Thanks for correcting my point.

Pedro