[Patches] [ python-Patches-453035 ] shrink frame objects

[noreply@sourceforge.net]

Patches item #453035, was opened at 2001-08-19 12:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=453035&group_id=5470

Category: core (C code)
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 3
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Neil Schemenauer (nascheme)
Summary: shrink frame objects

Initial Comment:
This patch reduces the size of frame objects.  A lot
of memory is used for the f_blockstack array.  Deeply
nested blocks are rarely used.  I believe the standard
test suite never uses any more than three blocks.
The patch reduces the size of the f_blockstack array
from 20 elements to 4.  The rest of the block stack is
allocated only if needed.  On my machine this change
reduces the size of the frameobject struct from 336
bytes to 148.


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

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-19 14:09

Message:
Logged In: YES 
user_id=35752

I had the patch around so I thought I would run it past
someone.  If it only saves 21KB for the average program
then it's not worth complicating the code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 13:36

Message:
Logged In: YES 
user_id=31435

Hmm!  Offhand I'm -0 on this:  I can see that it makes 
block-related operations more expensive, but don't know why 
I should care so much about how big a frame is that I 
should be keen to slow it in return for some space.

If you leave test_generators out of the test suite, only 
115 unique frame objects are allocated (on Windows -- 
perhaps a little different on Linux, since different tests 
get skipped), so this is a total savings of about 21KB.  
That seems trivial compared to the total MBs allocated.

If you include test_generators, it zooms to about 1800 
frame allocations (and so about 330KB potential saving) -- 
but test_generators is deliberately stressing the system.  
In most programs, the # of frames allocated is equal to the 
maximum call depth, and very deep recursion is avoided in 
Python for lots of reasons.

So, what's the value to you?  I suppose I'd like it better 
if you gave back 4 bytes to hold a pointer to the block 
stack (pointing either to the static stack or the malloc'ed 
one), so that PyFrame_BlockSetup and PyFrame_BlockPop 
didn't have to *compute* which stack to use on each call.  
This would require computing the max block stack depth at 
compile time.

BTW, I don't think you intended to inculde a setup.py patch 
in the attachment.

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

Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-19 12:45

Message:
Logged In: YES 
user_id=35752

Argh, forgot to check the upload box.


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

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