[Python-Dev] The future of the wchar_t cache

[Victor Stinner]

Le sam. 20 oct. 2018 à 18:02, Steve Dower <steve.dower at python.org> a écrit :
> I don't have numbers, but my instinct says the most impacted operations
> would be retrieving collections of strings from the OS (avoiding a
> scan/conversion for each one), comparisons against these collections
> (in-memory handling for hash/comparison of mismatched KIND), and passing
> some of these strings back to the OS (conversion back into UCS-2). This
> is basically a glob/fnmatch/stat sequence, and is the main real scenario
> I can think of where Python's overhead might become noticeable.

Use os.scandir() to avoid stat :-)

For code like "for name in os.listdir(): open(name): ...." (replace
listdir with scandir if you want to get file metadata), the cache is
useless, since the fresh string has to be converted to wchar_t*
anyway, and the cache is destroyed at the end of the loop iteration,
whereas the cache has never been used...

I'm not saying that the cache is useless. I just doubt that it's so
common that it really provide any performance benefit.

Victor