Lazy traceback objects

[kumaraditya303]

The idea here is to avoid creating traceback and frame objects when an exception is raised unless required. Currently, traceback objects are created eagerly and since traceback objects hold reference to frame objects, expensive PyFrameObject* are created.

As an example:

def func(x):
    try:
        return x.y
    except AttributeError:
        return None

func(1)

Here even though the traceback object was not accessed, it was created. This applies to all the exceptions as such StopIteration etc.
In the new optimized design we may lazily create a traceback if it is accessed by replacing __traceback__ with a descriptor and cache its value once traceback is created. This would avoid creation of most traceback and frame objects and should speed up exception handling. Traceback and frames are GC heavy objects so this should also help GC.

[iritkatriel]

What do we need to save in order to later have all the information we need to construct the traceback?

[kumaraditya303]

I think we can construct the traceback and frame object with _PyInterpreterFrame *.
We can set _PyInterpreterFrame.owner to FRAME_OWNED_BY_EXCEPTION like how it is done for generators with FRAME_OWNED_BY_GENERATOR and making the exception responsible for _PyInterpreterFrame *

[kumaraditya303]

PyFrameObject * is created from _PyInterpreterFrame *. PyTracebackObject * is created from PyFrameObject * with _PyTraceBack_FromFrame so _PyInterpreterFrame * has all the information from which both PyFrameObject * and PyTracebackObject * can be created.

[markshannon]

We will also need the instruction pointer/offset at the time the exception is raised, as well as the _PyInterpreterFrame, as frames can continue execution.

[markshannon]

@kumaraditya303 can you fill out the details. Specifically, what objects would be allocated when?
Will need to allocate some sort of object(s) when the exception is raised, but it could be a lot more efficient that creating two objects per frame.

As a simple first step, we could compute the line number lazily from lasti, instead of doing it eagerly.

[kumaraditya303]

Yes, first step would be defer the computation of line number. Upon reading _PyTraceBack_FromFrame, the frameobject is used just for calculating lineno, so deferring its creation until accessed via tb_frame attribute would be second step. I am thinking that the raised exception should take over the ownership of _PyInterpreterFrame and when the exception instance is deallocated, the interpreter frame would be deallocated (if not reachable from a frameobject).

[markshannon]

Want to make a PR for deferring the computation of line number?

[kumaraditya303]

Created draft PR python/cpython#95237, thanks for your support of idea!

[kumaraditya303]

I posted a microbenchmark result on the issue, it shows a 25% speedup when lazily computing lineno. See python/cpython#95238