Hi Serhiy, +1 to remove wchar_t cache. IMHO it wastes memory for no real performance gain.
By the way, can we start to schedule the *removal* of the Py_UNICODE API? For example, decide when Py_DEPRECATED is used in the C API? Should we start to deprecate when Python 2 reachs its end of life? Or can we *remove* this API as soon as Python 2 is dead? (Please, don't use "Python 4" as a milestone to introduce such backward incompatible change.) Le sam. 20 oct. 2018 à 15:05, Stefan Behnel <stefan...@behnel.de> a écrit : > I'd be happy to get rid of it. But regarding the use under Windows, I > wonder if there's interest in keeping it as a special Windows-only feature, > e.g. to speed up the data exchange with the Win32 APIs. I guess it would > have to provide a visible (performance?) advantage to justify such special > casing over the code removal. If someone wants to *keep* the cache, I would like to see: * statistics on the cache usage: how many strings are converted to wchar_t*? What is the percentage on all strings? * what is the cache hit? * what is the overhead of removing the cache? (on length 10, 100, 1000, 1 MB, 10 MB?) When you look at the performance of the str type, it's common that timings are smaller than 1 us. Each str function has been highly optimized. IMHO the conversion of a string to wchar_t* is cheap, especially because I expect that all strings used with the Windows API are shorter than 1,000 characters. Victor _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
