A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2018-October/155547.html below:

[Python-Dev] The future of the wchar_t cache

[Python-Dev] The future of the wchar_t cache [Python-Dev] The future of the wchar_t cacheVictor Stinner vstinner at redhat.com
Mon Oct 22 09:28:32 EDT 2018
Le lun. 22 oct. 2018 à 15:24, Steve Dower <steve.dower at python.org> a écrit :
> Yes, that's true. But "should reduce ... footprint" is also an
> optimisation that deserves a benchmark by that standard.

pyperformance has a mode to mesure the memory usage (mostly the memory
peak) if someone wants to have a look.

> Also, I'm
> proposing keeping the 'kind' as UCS-2 when the string is created from
> UCS-2 data that is likely to be used as UCS-2.

Oh. That's a major change in the PEP 393 design. You would have to
modify many functions in CPython. Currently, the PEP 393 requires that
a string always use the most efficient storage, and many optimizations
and code paths rely on that assumptions.

I'm against this change.

Moreover, it's hard to guess how a string will be used later...

Victor
More information about the Python-Dev mailing list

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