[Python-Dev] optimization required: .format() is much slower than %

Eric Smith eric+python-dev at trueblade.com
Tue May 27 03:04:47 CEST 2008


Gregory P. Smith wrote:
> My gut feels the same way...  How about seeing the profile data of the
> new vs old string formatting functions first as a comparison.  If
> those disagree vs the above then the ".format()" name lookup and
> function call overhead is likely consuming the time missing from a
> profile.

Because it's a more general and extensible mechanism, .format() will 
never be as fast as %-formatting.  But I agree it could no doubt be 
improved.

When implementing this, my gut feelings were that the performance 
difference is likely:

- "__format__" lookup.
- Each __format__() call returns an object.  The overhead is 
non-trivial, compared to the hard coded types in %-formatting.

Not that this means anything without actual profiling.

Here's about the best direct comparison I could think of:

$ ./python -m timeit "'nothing'.__format__('')"
1000000 loops, best of 3: 1.19 usec per loop
$ ./python -m timeit "'{0}'.format('nothing')"
100000 loops, best of 3: 3.74 usec per loop

Shows there is some overhead to the "format" lookup and result 
computation, but it's still much slower than:

$ ./python -m timeit "'%s' % 'nothing'"
1000000 loops, best of 3: 0.223 usec per loop



More information about the Python-Dev mailing list