
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