[Python-Dev] The future of the wchar_t cache

[Victor Stinner]

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_ml at 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