[Patches] [ python-Patches-864059 ] optimize eval_frame

[SourceForge.net]

Patches item #864059, was opened at 2003-12-21 13:30
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470

Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: optimize eval_frame

Initial Comment:
There are several different parts to this patch which
are separable.  They each seemed to have a small
benefit.  It would be interesting for others to test
this patch in whole and in different parts to see if
speed can be improved.  I generally got between 1% -
10% improvement.  I used pystone, pybench, and the
total time to run all regression tests.  Runs were on a
RH9 Linux/Athlon 650.  I used a non-debug build (so gcc
3.2 with -O3).  All regression tests pass with these
changes.

I removed registers from many variables.  This seemed
to have little to no effect.  So I'm not sure about
those.  opcode does not need to be initialized to 0.  I
removed the freevars variable since it is rarely used.

I think the largest benefit was from adding the gotos
for opcodes which set why:  BREAK_LOOP, CONTINUE_LOOP,
RETURN_VALUE, YIELD_VALUE;  This skips many tests which
are known a priori depending on the opcode.

I removed the special check for list in UNPACK_SEQUENCE
since this path is rarely used. 
(http://coverage.livinglogic.de/file.phtml?file%5fid=12442339)
 I also removed the predcitions for JUMP_IF_TRUE since
this wasn't executed often (see previous URL).

I added 2 opcodes for calling functions with 0 or 1
arguments.  This removed a lot of code in
call_function().  By removing test branches in  several
places, this seemed to speed up the code.  However, it
seemed that just specializing for 0 arguments was
better than for 1 arg.  I'm not sure if the
specialization for 1 argument provides much benefit. 
Both of these specializations could possibly be
improved to speed things up.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-24 03:20

Message:
Logged In: YES 
user_id=80475

I'll try these out and review the patch when I get back from 
vacation next week.  

The list special case for UNPACK_SEQUENCE and the 
prediction for JUMP_IF_TRUE should be left in -- they do 
provide speed-ups for code that exercises those features and 
they don't hurt the general cases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=864059&group_id=5470