26.02.12 14:42, Armin Ronacher написав(ла):
> On 2/26/12 12:35 PM, Serhiy Storchaka wrote:
>> Some microbenchmarks:
>>
>> $ python -m timeit -n 10000 -r 100 -s "x = 123" "'foobarbaz_%d' % x"
>> 10000 loops, best of 100: 1.24 usec per loop
>> $ python -m timeit -n 10000 -r 100 -s "x = 123" "str('foobarbaz_%d') % x"
>> 10000 loops, best of 100: 1.59 usec per loop
>> $ python -m timeit -n 10000 -r 100 -s "x = 123" "str(u'foobarbaz_%d') % x"
>> 10000 loops, best of 100: 1.58 usec per loop
>> $ python -m timeit -n 10000 -r 100 -s "x = 123; n = lambda s: s"
> "n('foobarbaz_%d') % x"
>> 10000 loops, best of 100: 1.41 usec per loop
>> $ python -m timeit -n 10000 -r 100 -s "x = 123; s = 'foobarbaz_%d'" "s
> % x"
>> 10000 loops, best of 100: 1.22 usec per loop
>>
>> There are no significant overhead to use converters.
> That's because what you're benchmarking here more than anything is the
> overhead of eval() :-) See the benchmark linked in the PEP for one that
> measures the actual performance of the string literal / wrapper.
$ python -m timeit -n 10000 -r 100 ""
10000 loops, best of 100: 0.087 usec per loop
Overhead of eval is 5%.
Real code is not single string literal, every string literal occured
together with a lot of code (getting and setting variables, attribute
access, function calls, binary operators, unconditional and conditional
jumps, etc), and total effect of using simple converter will be
insignificant.
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