[Python-Dev] [ python-Patches-876206 ] scary frame speed hacks

[Tim Peters]

[Neal Norwitz]
> In Include/frameobject.h, b_type and b_level can be combined to
> a single 32-bit value, rather than two in PyTryBlock.  There
> is a bit more processing to pull the values apart.  IIRC,
> there was a very small, but measurable performance hit.
> You can also decrease CO_MAXBLOCKS.  I was able to drop the
> size to under 256 bytes.  But perf was still a bit off.

PyTryBlock is indeed the frameobject memory pig, but it shouldn't need to
be -- the size needed varies by code object, but is fixed per code object,
and is usually very small (IIRC, it's the max nesting depth in the body of
the code, counting only nested loops and "try" structures (not counting
nested def, class, or "if" structures)).  So it should be possible, e.g., to
shove it off to the variable-size tail of a frame, and allocate only exactly
as much as a given code object needs.  For that matter, we wouldn't need an
arbitrary upper bound (currently 20) on nesting depth then either.

> My goal was to drop the frame size small enough for PyMalloc.
> I don't think I ever tried to change the allocs.  But since
> I never got it faster, I dropped it.

Note that since frames participate in cyclic gc, each needs another 12
(Linux) or 16 (Windows) bytes for the gc header too.  That's why I said ">
350" at the start when everyone else was quoting basicsize as if the latter
had something to do with reality <wink>.