[Patches] [ python-Patches-561244 ] Micro optimizations

noreply@sourceforge.net noreply@sourceforge.net
Fri, 13 Sep 2002 08:19:44 -0700


Patches item #561244, was opened at 2002-05-27 17:33
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=561244&group_id=5470

Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Micro optimizations

Initial Comment:
This is stuff I've had sitting around for a while.
I was attempting to improve performance in
some paths.

 * Most of the changes are from a loop -> memset.
 * intobject changes are to initialize small ints at
startup,
   so smallints don't have to be checked for each new int
 * other misc very small clean-ups

Please review and test to see if there are any
problems.  Also feedback whether this improves
performance for various platforms (tested on Linux)
or if this patch is even worth it.

Files modified are:  Include/intobject.h
Python/{ceval,pythonrun}.c
Objects/{tuple,list,int,frame,}object.c

All changes are independant, except for the int changes
which affect:  Include/intobject.h, Python/pythonrun.c,
and Objects/intobject.c.
It may also be useful to define the small negative int
(NSMALLNEGINTS) to be 5 or so instead of 1.  There are
several uses -2, -3, ... in the standard library.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-13 11:19

Message:
Logged In: YES 
user_id=33168

I've updated the patch.  It's more of the same types of changes:
 * intobject stuff is the same, ie allocate small ints on
startup
   - the only change is to bump NSMALLNEGINTS from 1 to 5
 * frameobject: intern "__builtins__" on startup not in
Frame_New
 * DECREF instead of XDECREF in frame for code, builtins,
and globals
   (note, INCREF was used for these, not XINCREF)

I've been running with these for months, so I'm pretty sure
they are safe.
Unless you changed your mind about the int changes, these
changes should
be ok too.  Just giving you one last chance to change your
mind. :-)

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-09-08 20:28

Message:
Logged In: YES 
user_id=33168

No, I've still got some outstanding modifications.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-09-08 00:57

Message:
Logged In: YES 
user_id=80475

Are these all done now?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-07-03 11:59

Message:
Logged In: YES 
user_id=33168

Checked in the memset()s in:
  {list,tuple}object.c and _sre.c.
object.c 2.178

Still have to do int and frame.
I've cleaned up int so that if there is an init
failure, a fatal error is raised similar to other
initializations.  I will get around to checking that in.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 17:43

Message:
Logged In: YES 
user_id=6380

I like all of these, even PyInt_Init(). Go for it.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-31 18:11

Message:
Logged In: YES 
user_id=80475

Wow, you plowed through a lot of code!

Two sets of optimizations look worthwhile, the memsets() 
and the XINCREFs to INCREFS.

Probably the fastlocals substitutions should be done also, 
but more for beauty and clarity than speed.

I checked those three categories of changes on my 
machine.  They compile fine, pass the standard regression 
tests and checkout okay on my personal, realcode 
testfarm.

I don't think the PyInt_Init() addition buys us anything.  
The register and macro tweaks may cost more in review 
time and potential errors than they could ever save in 
cumulative computer time.

Recommend you get these in before someone changes the 
codebase.



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

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