Concerns about performance w/Python, Pysco on Pentiums

[Pedro Rodriguez]

On Fri, 07 Mar 2003 13:34:30 +0000, Peter Hansen wrote:

> Andrew Bennetts wrote:
>> 
>> 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.
> 
> Andrew is quite right.  Naturally, unimplemented opcodes are in effect
> *never* encountered in valid code, and that feature is there for now
> only because 34 out of about 200 opcodes have been implemented.  
> 

I understand, and agree, with the reasoning behind Andrew and John
remarks. Just for the purpose of the exercise, I will add some points.

I understand that you can live with performance as it is, but if some
basic optimisation or tool can buy you some time, you'll may make the
effort of using it as long as it keep the code simple and maintenable.

Let's consider that current performance is a problem, without loosing
focus on maintenability. By design you'll have to consider what functions
are critical, using a profiler for instance will show you what functions 
are heavily used or what are the one that too expensive.

Optimization can be done by redesigning some aspects of the application
in regard with data organization and data flow.

If the method "step" were to be the time critical function of your code,
what can be done to improve it. 

If I focus on the "try/except", and pick up your comment that this should
not be frequent to fall in the exception case, so why clutter your code
with this test (or any test, like the one I posted) ? Just consider that
all opcodes are valid, but that the action for some will raise the
exception (def executeINVALIDOPCODE(): raise ...). 

You'll simplify, and do some basic optimization, in the flow of your
code, without adding extra complexity, and using your data organization 
at best. I don't know what your real cpu will do in this case, but you 
may even implement the proper behaviour.

What about the next test, with the returned new PC, why not have the
opcode method do the proper job, only when needed (by passing the
opcode mode to the execute method, or just knowing, by design of the
opcode method, how it will affect the CPU PC).

Just-thinking-loud'ly y'rs,
Pedro