Optimize calling str() and unicode()
They are tricky since these are types, which means they invoke the relatively-complicated constructor logic. ie str() doesn't just call __str__ on the argument: if the result is a subclass of str, it calls result.__init__(). Similarly for unicode, except unicode is even trickier since it takes some more arguments, one of which is "encoding" which will have non-type-based dynamic behavior. I didn't realize that at first and optimized unicode() by exposing an inner version of it that takes its arguments in registers, which we can take advantage of using our jit-arg-rearrangement capability. This means we have to do parts of PyArg_ParseTuple ourselves, so I added a PyArg_ParseSingle that runs a single object through the arg-conversion code. PyArg_ParseSingle could be further optimized if we want to. Or rather, if we have functions of the form PyArg_ParseSingle_s (which corresponds to the "s" format code) we could skip some more of the overhead. I had to disable most of that once I realized the encoding issue, but I left it in since hopefully we will be able to use it again once we have some "do some guards after mutations if we know how to resume after a failed guard" rewriter support.
Showing
This diff is collapsed.
test/tests/encoding_test.py
0 → 100644
Please register or sign in to comment