Eric Smith trueblade.com> writes:
>
> I finally backported this to 2.6 in r65814. There's a similar 30%
> speedup for the simplest cases. Unicode optimization is worse than
> string optimization, because of the way int, long, and float formatters
> work. This can be fixed, but I'm not sure
Eric Smith wrote:
Eric Smith wrote:
Eric Smith wrote:
Nick Coghlan wrote:
Secondly, the string % operator appears to have an explicit
optimisation for the 'just return str(self)' case. This optimisation
is missing from the new string format method.
I'll see if I can optimize this case.
3.
Eric Smith wrote:
Eric Smith wrote:
Nick Coghlan wrote:
Secondly, the string % operator appears to have an explicit
optimisation for the 'just return str(self)' case. This optimisation
is missing from the new string format method.
I'll see if I can optimize this case.
3.0, from svn:
$ ./py
Simon Cross wrote:
It struct me as odd that this one case shows such a big difference
while the others show less of one.
I believe the %-formatting code has some optimisations in place where it
realises it can just increment the reference count of the passed in
string and return that, rather
On Tue, May 27, 2008 at 12:43 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Ten minutes ago I raised a concern about speed differences between the
> old style % formatting and the new .format() code. Some quick
> benchmarking from Benjamin and me showed, that it's even worse than I
> expected.
Nick Coghlan wrote:
[EMAIL PROTECTED] wrote:
Nick> $ ./python -m timeit "'' % ()"
Nick> 100 loops, best of 3: 0.389 usec per loop
vs.
Nick> $ ./python -m timeit "'%s' % 'nothing'"
Nick> 1000 loops, best of 3: 0.0736 usec per loop
I think you need to use a tuple for the
[EMAIL PROTECTED] wrote:
Nick> $ ./python -m timeit "'' % ()"
Nick> 100 loops, best of 3: 0.389 usec per loop
vs.
Nick> $ ./python -m timeit "'%s' % 'nothing'"
Nick> 1000 loops, best of 3: 0.0736 usec per loop
I think you need to use a tuple for the second case to make
Nick> $ ./python -m timeit "'' % ()"
Nick> 100 loops, best of 3: 0.389 usec per loop
vs.
Nick> $ ./python -m timeit "'%s' % 'nothing'"
Nick> 1000 loops, best of 3: 0.0736 usec per loop
I think you need to use a tuple for the second case to make it comparable to
the first
Christian Heimes wrote:
Antoine Pitrou schrieb:
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 form
Antoine Pitrou schrieb:
> 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.
10 matches
Mail list logo
