Logged In: YES 
user_id=80475

The patch is promising.  I'm able to measure a small speed-
up for the two new function opcodes and for the setwhy 
gotos.  Both optimizations make sense.

I don't measure a savings from not initializing opcode and 
oparg.  That change makes sense conceptually because the 
variables are always assigned before use; however, the 
surrounding control flow statements hide that fact from the 
compiler.  So, it is likely that they were initialized to 
suppress warnings on somebody's system.  If so, then that 
change should not be made.

The other stuff should definitely be left out.  The effect of 
register variables will vary from compiler to compiler, so if 
you can't measure an improvement, it is best to leave it 
alone.  Some compilers do not do much in the way of 
optimization and the register declaration may be a valuable 
hint.

Please leave in the branch prediction for JUMP_IF_TRUE -- I 
put it in after finding measurable savings in real code.  While 
it doesn't come up often, when it does it should run as fast 
as possible.

The special case for UNPACK_SEQUENCE is up for grabs.  
When that case occurs, the speedup is substantial.  Also, 
given that the tuple check has failed, it becomes highly 
probable that the target is a list.  OTOH, this inlined code 
fattens the already voluminuous code for eval_frame.  Maybe 
eliminating it will help someone's optimizer cope with all the 
code.  Use your judgement on this one.

Removing the freevars variable did not show any speedup. It
does keep one variable off the stack and shortens the startup 
time by a few instructions.  OTOH, the in-lined replacements 
for it result in a net expansion of code size and causes a 
microscopic slowdown whenever it is used.  I recommend 
leaving this one alone.

Executive summary:  Only make the two big changes that 
show meaurable speedups and make conceptual sense.  
Leave the other stuff alone.

One other thought, try making custom benchmarks for 
targeted optimizations.  The broad spectrum benchmarks are 
too coarse to tell whether an improvement is really working.

Also, be sure to check with Guido before adding the new 
opcodes.

Ideally, each optimization should be loaded separately so its 
effects can be isolated and to allow any one to be backed out 
if necessary.