В методе timeit по умолчанию 1000000 отераций )))

да, это действительно так. ахаха, как это смешно ))0ноль)

В методе timeit по умолчанию 1000000 отераций )))

потому что это язык высокого уровня.

по поводу фактической производительности. измерение всего одной итерации всегда будет давать разный результат.

print(timeit.Timer("f2(1, 2)", "from __main__ import f2").timeit(1000000))
print(timeit.Timer("f1(1, 2)", "from __main__ import f1").timeit(1000000))

3.90879893303
2.2824139595

быстрее не в 4 и не в 2 раза.

плюс с использованием *args, **kwargs, timeit() при разных замерах даёт отношение первого времени ко второму с вариациями +-10%, что говорит или о том, что timeit() не точен, или о том же, о чём я на писал в первом абзаце.

но в целом убедили, да. если дизассемблировать код и считать инструкции, то можно написать быстрее.

t_closure = 0.7415
t_class = 1.383
t_empty = 0.285

( 1.383 – 0.285 ) / ( 0.7415 – 0.285 ) = 2.4

> “питоновские инструкции” – это бред. хотите считать инструкции – пишите на ассемблере. питон – это язык высокого
> уровня, хотите мерять производительность….

Подавляющее большинство низкоуровневых питоновских инструкций исполняются за примерно одинаковое время
(а менно такие как add,getattr,getitem,mul,… , усли конечно соотв. операторы не перегружены python/C кодом
на что-нить нетривиальное)

Мерять такой код профайлером – мягко говоря неправильно т.к. накладные расходы профайлера ЗНАЧИТЕЛЬНО превышают время исполнения кода(что мы тут и видим). Для таких случаев давно уже есть timeit(о чем я,кстати, писал)

WinXP SP2,AthlonX2 3600@2.9Ghz

Python 3.0a1 (py3k:57844, Aug 31 2007, 16:54:27) [MSC v.1310 32 bit (Intel)] on win32

>>> def closure(func):
counter = 1
def cl(x):
nonlocal counter
counter += 1
return func(counter,x)
return cl
>>> class ccl:
def __init__(self,func):
self.func = func
self.counter = 1
def __call__(self,val):
self.counter += 1
return self.func(self.counter,val)
>>> @closure
def f1(x,y):
pass #мы вроде не сложение меряем а замыкания
>>> @ccl
def f2(x,y):
pass
>>> def
>>> f1(1)
>>> import timeit
>>> timeit.Timer("f1(1)","from __main__ import f1").timeit()
0.70828024232130105
>>> timeit.Timer("f2(1)","from __main__ import f2").timeit()
1.8935336753693548
>>> def f3(x,y):pass
>>> timeit.Timer("f3(1,1)","from __main__ import f3").timeit()
0.31531297972230732

С классом в 4(ЧЕТЫРЕ) раз медленнее.


спасибо, что продолжаете нести бремя додумывания. у вас это хорошо получается.

в PEP’е, к счастью, приведён более вменяемый пример, теперь вроде бы понятно зачем нужен nonlocal. только в том примере работа с переменной не в глобальной, и не в локальной области видимости. можно ли считать эо замыканием – не знаю. технически, наверное да. но тогда можно глобальную область видимости назвать “такое большое замыкание”. но это не важно, спасибо за разъяснения.

Для 2.X скорость отличается не сильно в данном случае т.к. здесь присутствует оператор [], который трансформируется в три питоновские инструкции. Для 3.0 в этом месте нет дополнительных инструкций. Вариант через классы при каждом обращении к атрибуту требуют
двух дополнительных инструкций. Если бы счетчик не требовался то через замыкания было-бы быстрее и в 2.X.

сначала не хотел на это отвечать, потому что мерять “питоновские инструкции” – это бред. хотите считать инструкции – пишите на ассемблере. питон – это язык высокого уровня, хотите мерять производительность – берите хотя бы профайлер. сто раз это уже обмусоливалось, производительность программы зависит от алгоритмов, а не от 2 лишних инструкций.

всё-таки запустил профайлер на python3.

код f_dec стал выглядеть так:

def f_dec(func):
non_local = 0
def dec(*args, **kwargs):
nonlocal non_local
non_local += 1
return func(*args, **kwargs)
return dec

ncalls tottime percall cumtime percall filename:lineno(function)
1 0.000 0.000 0.000 0.000 :0(__build_class__)
2/1 0.000 0.000 97.174 97.174 :0(exec)
1 0.004 0.004 0.004 0.004 :0(setprofile)
2/1 26.746 13.373 97.174 97.174 :1()
1 0.000 0.000 0.000 0.000 :1(f_dec)
1 0.000 0.000 0.000 0.000 :10(__init__)
1000000 24.558 0.000 35.290 0.000 :13(__call__)
1000000 11.193 0.000 11.193 0.000 :18(test1)
1000000 10.733 0.000 10.733 0.000 :22(test2)
1000000 23.946 0.000 35.138 0.000 :3(dec)
1 0.000 0.000 0.000 0.000 :9(c_dec)
1 0.000 0.000 97.178 97.178 profile:0(exec('..
0 0.000 0.000 profile:0(profiler)

ерунда. ч.т.д.

Нет. Если очень нужно используйте numpy –
там есть тип для массивов с произвольными Python объектами.
http://www.python.org/dev/peps/pep-0209/

http://www.python.org/dev/peps/pep-3104/ раздел Rationale, если и после этого будет “не ясно”
можно написать в python-dev-request@python.org что замыкания не нужны а nonlocal так вообще нафик.

> почему-то получается не в два раза быстее, а как-то.. одинаково.

Для 2.X скорость отличается не сильно в данном случае т.к. здесь присутствует оператор [],
который трансформируется в три питоновские инструкции. Для 3.0 в этом месте нет дополнительных
инструкций. Вариант через классы при каждом обращении к атрибуту требуют
двух дополнительных инструкций. Если бы счетчик не требовался то через замыкания было-бы быстрее
и в 2.X.