Some crude timeit benchmarks:

This PR

$ ./python.exe -m timeit "str(1)"
5000000 loops, best of 5: 58.6 nsec per loop
$ ./python.exe -m timeit "str(b'a', 'latin1')"
10000000 loops, best of 5: 39.1 nsec per loop
$ ./python.exe -m timeit "str(b'a', 'latin1', errors='strict')"
5000000 loops, best of 5: 50 nsec per loop

# fallback to tp_call
$ ./python.exe -m timeit "str(object=b'a', encoding='latin1', errors='strict')"
2000000 loops, best of 5: 185 nsec per loop

`main`

$ ./python.exe -m timeit "str(1)"
5000000 loops, best of 5: 56.7 nsec per loop
$ ./python.exe -m timeit "str(b'a', 'latin1')"
5000000 loops, best of 5: 75.4 nsec per loop
$ ./python.exe -m timeit "str(b'a', 'latin1', errors='strict')"
2000000 loops, best of 5: 145 nsec per loop
$ ./python.exe -m timeit "str(object=b'a', encoding='latin1', errors='strict')"
2000000 loops, best of 5: 182 nsec per loop

So there is a nice speedup for the fast paths that were added, no change for the single param case, and not a lot of overhead for the fallback cases. I guess the question now is how many cases we want to add; IOW, how much complexity do we allow.

Uh oh!

PyUnicode_Type needs vectorcall. #117709

Description

Linked PRs

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

`PyUnicode_Type` needs vectorcall. #117709