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

Gregory P. Smith greg at krypto.org
Tue May 27 02:17:31 CEST 2008

On Mon, May 26, 2008 at 3:43 PM, Christian Heimes <lists at cheimes.de> wrote:

Dear fellow Python developers!

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. $ ./python -m timeit "'%s'.format('nothing')" 100000 loops, best of 3: 2.63 usec per loop $ ./python -m timeit "'%s' % 'nothing'" 10000000 loops, best of 3: 0.188 usec per loop $ ./python -m timeit "'some text with {0}'.format('nothing')" 100000 loops, best of 3: 4.34 usec per loop $ ./python -m timeit "'some text with %s' % 'nothing'" 100000 loops, best of 3: 2.04 usec per loop $ ./python -m timeit "'some text with {0} {1}'.format('nothing', 'more')" 100000 loops, best of 3: 6.77 usec per loop $ ./python -m timeit "'some text with %s %s' % ('nothing', 'more')" 100000 loops, best of 3: 2.22 usec per loop As you can clearly see the new .format() code is much slower than the old style % code. I recommend we spend some time on optimizing common code paths of the new .format() code. As first step I propose the move the format method to a new type slot. format() is called for every object. My gut feeling says that a slot method is going to speed up the most common usage "{0}".format(somestring).

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.

-gps

More information about the Python-Dev mailing list