[Python-Dev] optimization required: .format() is much slower than % (original) (raw)
Eric Smith eric+python-dev at trueblade.com
Tue May 27 03:04:47 CEST 2008
- Previous message: [Python-Dev] optimization required: .format() is much slower than %
- Next message: [Python-Dev] optimization required: .format() is much slowerthan %
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] optimization required: .format() is much slower than %
- Next message: [Python-Dev] optimization required: .format() is much slowerthan %
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]