[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