[Cython] Redundant Cython exception message strings

Robert Bradshaw robertwb at math.washington.edu
Sat May 28 00:39:36 CEST 2011


On Fri, May 27, 2011 at 3:32 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I recently stumbled over a tradeoff question with AttributeError, and now
> found the same situation for UnboundLocalError in Vitja's control flow
> branch. So here it is.
>
> When we raise an exception several times in different parts of the code with
> a message that only differs slightly each time (usually something like
> "'NoneType' has no attribute X", or "local variable X referenced before
> assignment"), we have three choices to handle this:
>
> 1) Optimise for speed: create a Python string object at module
> initialisation time and call PyErr_SetObject(exc_type, msg_str_obj).
>
> 2) Current way: let CPython create the string object when raising the
> exception and just call PyErr_SetString(exc_type, "complete message").
>
> 3) Trade speed for size and allow the C compiler to reduce the storage
> redundancy: write only the message template and the names as C char*
> constants by calling PyErr_Format(exc_type, "message template %s", "X").
>
> Assuming that exceptions should be exceptional, I'm leaning towards 3). This
> would allow the C compiler to collapse multiple usages of the same C string
> into one data constant, thus reducing a bit of redundancy in the shared
> library size and the memory footprint. However, it would (slightly?) slow
> down the exception raising due to the additional string formatting, even
> when compared to the need to build a Python string object that it shares
> with 2). While 1) would obviously be the fastest way to raise an exception
> (no memory allocation, only refcounting), I think it's not worth it for
> exceptions as it increases both the runtime memory overhead and the module
> startup time.
>
> Thoughts?

Any back-of-the-envelope calculations on how much the savings would
be? I think I'm leaning towards 3 as well, certainly not option 1.

- Robert


More information about the cython-devel mailing list