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/2008-May/079800.html below:

.format() is much slower than %

[Python-Dev] optimization required: .format() is much slower than % [Python-Dev] optimization required: .format() is much slower than %Gregory P. Smith greg at krypto.org
Tue May 27 18:38:24 CEST 2008
On Tue, May 27, 2008 at 3:12 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Nick Coghlan <ncoghlan <at> gmail.com> writes:
>>
>> The only optimisation idea I came up with (other than the addition of a
>> tp_format slot) is for string objects to be able to cache their
>> (lookup:subformat) pairs rather than having to parse themselves every
>> time. That has obvious memory consumption implications though.
>
> If a string is used as a formatting template, it is bound to be used again as
> such. So IMHO it sounds quite reasonable.
>
> In order to avoid memory consumption issues there could be a centralized cache
> as for regular expressions. It makes it easier to handle eviction based on
> various parameters, and it saves a few bytes for string objects which are never
> used as a formatting template.
>
> Regards
>
> Antoine.

+1 to that idea.
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