Thanks for trying it! I'm curious why it would be slower (perhaps less locality? perhaps the ...Id... APIs have some other trick up their sleeve?) but since it's also messier and less backwards compatible than just leaving _Py_IDENTIFIER alone and just not using it, I'd say let's not spend more time on that alternative and just focus on the two other horses still in the race: immortal objects or what you have now.
On Fri, Feb 4, 2022 at 8:25 PM Eric Snow <ericsnowcurrently@gmail.com> wrote:
> On Fri, Feb 4, 2022, 16:03 Guido van Rossum <guido@python.org> wrote:
>> I wonder if a better solution than that PR wouldn't be to somehow change the implementation of _Py_IDENTIFIER() to do that,
>
> Yeah, I had the same realization today. I'm going to try it out.
I updated _Py_IDENTIFIER() to use a statically initialized string
object and it isn't too bad. The tricky thing is that PyASCIIObject
expects to the data to be an array after the object. So the field
must be a pre-sized array (like I did in gh-30928). That makes things
messier. The alternative is to do what Steve is suggesting.
I ran the benchmarks and making _Py_IDENTIFIER() a statically
initialized object makes things 2% slower (instead of 1% faster).
There are a few things I could do to speed that up a little, but at
best we'd get back to performance-neutral.
-eric
--