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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4