[Python-Dev] The future of the wchar_t cache (original) (raw)

Victor Stinner vstinner at redhat.com
Mon Oct 22 04:13:06 EDT 2018

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

More information about the Python-Dev mailing list