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(some_string). 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
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