Вызов функции: сколько стоит, что при этом не происходит и где живут ячейки

Сколько стоит вызов

Почти все числа сняты на вызове пустой функции: тело ничего не делает, и меряется только то, что происходит вокруг него. Две строки стоят ради масштаба: p.x — чтение слота, вызова в нём нет вовсе, и len_(data) — функция на C.

Числа из bench/calls/cost.py, один прогон 3.13.7; сравнивать их можно только между собой.

Почему метод почти не дороже функции

По модели данных o.m создаёт объект связанного метода, и вызов должен был бы стоить дороже. На быстром пути этого объекта нет вовсе: интерпретатор видит, что сразу за чтением атрибута стоит вызов, и кладёт на стек функцию и экземпляр по отдельности. Связывать их в один объект не нужно.

А что без вызова объект действительно создаётся, видно по одной строке:

o.m is o.m    # False
o.m == o.m    # True

Отсюда и совет, который лучше не выполнять: bound = o.m возвращает этот объект, и вызов начинает идти через него. Итог — 18,34 против 17,74 наносекунды: дешевле не стало, а что стало дороже, замер не доказывает — разница меньше разброса между раундами.

Звёздочки

Дорога одна форма из пяти: f3(**kwargs) впятеро дороже прямой передачи. f3(*args) — всего на шестнадцать процентов.

Причина в том, что позиционные аргументы и значения именованных едут массивом, а имена именованных — отдельным кортежем. Позиционные уже лежат так, как надо, и отдаются как есть; словарь не лежит ни тем, ни другим, и его приходится разобрать на массив значений и кортеж имён. Дело не в числе значений, а в том, что одну структуру приходится превращать в две другие.

Где живёт переменная замыкания

Замыкание держит не значение, а ячейку — отдельный объект, видимый из Python как элемент __closure__. Из этого следует всё остальное.

Две функции, созданные рядом, ссылаются на одну и ту же ячейку, и increment.__closure__[0] is read.__closure__[0] даёт True. Никто никому ничего не передавал: они просто смотрят в одну коробку.

Три лямбды из цикла тоже делят одну ячейку — потому что ячейка заводится на переменную, а переменная в цикле одна. К моменту вызова в ней лежит последнее значение, отсюда [2, 2, 2]. Это не отдельное правило про циклы и не ошибка.

Запись lambda i=i: i не «чинит связывание», а избавляет от нужды в общей коробке: у таких функций __closure__ пуст, а значение вычислено при создании каждой.

Бояться замыканий из-за скорости не нужно: чтение из ячейки стоит 3,91 наносекунды против 3,96 у локальной переменной и 3,78 у глобальной — все три неразличимы, и каждая — лишь доля пустого вызова.

Что из этого делать

Не переписывать o.m() в bound = o.m ради скорости. Не выбирать staticmethod и classmethod по скорости — только по смыслу. Из звёздочек остерегаться стоит только **kwargs на горячем пути. И помнить про ячейку: она одна на всех, кто видит переменную, — вот что в замыканиях действительно стоит внимания.

Про цену вызова в Python ходят три утверждения, и проверяются они одним и тем же замером: «вызов метода дороже вызова функции», «связать метод заранее дешевле, чем каждый раз через точку», «staticmethod быстрее обычного метода — у него нет self».

Первое замер почти не подтверждает. Второе не подтверждает тоже, а третье опровергает — и в обратную сторону: staticmethod не быстрее, а медленнее.

Объяснение у всех трёх одно, и оно не про наносекунды: на быстром пути вызова метода объект связанного метода не создаётся. Экономить на его создании нечего, а тот, кто «оптимизирует» вызов, связав метод заранее, этот объект возвращает.

Вторая половина статьи — про замыкания, и она здесь не за компанию. Ячейка — это то место, где живёт переменная, которую видит вложенная функция, и из её устройства следует всё остальное: общая переменная у двух функций, три одинаковых ответа из цикла и то, зачем нужен nonlocal.

Часть I. Цена вызова

Что вообще меряется

Почти все числа сняты на вызове пустой функции: тело ничего не делает, и меряется только то, что происходит вокруг тела. Две строки выпадают из этого нарочно, и обе стоят ради масштаба: p.x — чтение атрибута у объекта с __slots__, то есть самое дешёвое чтение, какое есть, и вызова в нём нет вовсе; len_(data) — вызов функции, написанной на C, а не на Python. Замер на 3.13.7, bench/calls/cost.py, блок 2:

Читается это так: пустой вызов на этой машине — около пятнадцати наносекунд, то есть примерно вдвое дороже самого дешёвого чтения атрибута, какое тут есть. Это сравнение масштаба двух разных операций, а не разложение цены вызова на слагаемые: из чего складываются эти пятнадцать наносекунд, замер не говорит вовсе. Всё остальное в таблице — надбавки за форму.

Три утверждения и что с ними стало

Тот же прогон, bench/calls/cost.py, блок 3:

Первое почти не подтверждается: шестнадцать процентов — не повод что-то переписывать, и это меньше, чем разница между f1(1) и f1(a=1) в той же таблице: 16,65 против 25,39.

Второе не подтверждается: заранее связанный метод во всяком случае не дешевле. Что он дороже, эти два числа не доказывают; почему — разобрано ниже, в отдельном разделе про разброс.

Третье опровергнуто, причём в обратную сторону: staticmethod медленнее обычного метода, а classmethod — заметно медленнее обоих. Но в этом сравнении меняются сразу две вещи, поэтому ниже они разобраны по отдельности.

Сначала — что здесь сравнивается с чем

В третьей строке таблицы стоят o.m() и C.s(), и различаются они сразу двумя вещами: видом метода и тем, через что его читают, — через экземпляр или через класс. Пока обе оси смешаны, разницу нельзя приписать виду метода: она могла взяться и от чтения через класс.

Поэтому обе оси разведены отдельным прогоном, в котором все шесть форм сняты вместе, — bench/calls/forms.py, блок 1:

Теперь каждое сравнение меняет ровно одну вещь. При одинаковом чтении — через экземпляр — staticmethod стоит ×1,54 от обычного метода, а classmethod ×2,72. Сам способ чтения при том же виде метода добавляет ×1,07 и ×1,09, то есть единицы процентов.

Вывод от разведения не перевернулся: staticmethod действительно дороже обычного метода, и дело именно в виде метода, а не в том, что его читали через класс. Но сказать это можно только теперь.

Почему так: что именно не происходит

Ответ на все три сразу лежит в байт-коде. bench/calls/shapes.py, блок 1, разбирает эти формы после двухсот прогревочных вызовов каждой:

Смотреть надо на строку o.m(t) и на последнюю. Инструкция чтения атрибута разная: LOAD_ATTR_METHOD_WITH_VALUES, когда сразу за чтением стоит вызов, и обычный LOAD_ATTR, когда вызова нет.

Разница в том, что кладётся на стек. На пути с вызовом туда попадают функция и экземпляр по отдельности: связывать их в один объект не нужно, и объект связанного метода не создаётся вовсе. На пути без вызова он создаётся, потому что его запросили.

Что без вызова объект действительно создаётся, можно проверить и без всякого байт-кода:

o.m is o.m    # False
o.m == o.m    # True

Два чтения подряд дают два разных объекта. Именно этой работы и нет на быстром пути.

И третье утверждение видно в той же таблице. У C.s(t) инструкций три, а не две: сначала читается имя класса, потом атрибут на нём, и специализации на экземпляре здесь нет вовсе. Это та самая ось «способ чтения», которой матрица выше отводит ×1,07; остальное — вид метода: ×1,54 при одинаковом чтении через экземпляр, вместе ×1,64 (28,45 против 17,33 в прогоне матрицы; ×1,57 в таблице утверждений — другой прогон). Байт-код o.s(t) этот прогон не разбирает, так что разложение получено по времени, а не по инструкциям. У C.c(t) то же лишнее чтение атрибута, но вызов идёт ещё и через связанный метод: CALL_BOUND_METHOD_EXACT_ARGS. Во что обходится каждая из двух добавок по отдельности, этот замер не раскладывает — виден только итог, 46,89 против 27,88.

Отсюда же ответ и на второе утверждение. Связать метод заранее — значит создать объект PyMethodObject один раз и вызывать через него: CALL_BOUND_METHOD_EXACT_ARGS. Экономить нечего — на быстром пути этот объект и так не создаётся, — а лишний уровень косвенности остаётся.

Числа при этом говорят меньше, чем хочется. 18,34 против 17,74 — это три процента, и прежде чем на такую разницу опираться, надо знать разброс. Числа ниже свои — это другой прогон, и с числами выше они не сравниваются; сравнивать надо разрыв внутри этого прогона с его же разбросом. Лучший и худший раунд из семи для каждой формы печатает bench/calls/forms.py, блок 2:

Разница между двумя формами что-то значит только там, где она больше разброса. У bound() и o.m() она составляет 1,28 нс при разбросе внутри раундов до 2,24 нс — это меньше разброса.

То есть «заранее связанный метод медленнее» из этих замеров не следует: два числа лежат внутри собственного шума. Следует другое — что он не дешевле, и это ровно тот вывод, который нужен на практике: связывать метод заранее ради скорости не стоит, потому что выигрыша нет ни в одном прогоне. А нужен заранее связанный метод тогда, когда его надо куда-то передать.

Звёздочки: дорога одна форма из пяти

«Звёздочки дорогие» — ещё одно ходовое убеждение, и верно оно ровно в одном случае из пяти. bench/calls/cost.py, блок 4:

f3(1, 2, 3) меряется здесь заново — отсюда 20,17 против 20,22 в таблице выше. Разница в пять сотых наносекунды — это одна и та же величина, дважды измеренная в одном прогоне. Значима ли разница, дальше решает разброс между раундами, а не эта величина.

Распаковка кортежа почти бесплатна — шестнадцать процентов. Приём в звёздочки стоит вдвое, и это нормальная цена за произвольную сигнатуру. А вот распаковка словаря на передаче обходится впятеро дороже, и только здесь есть о чём задуматься.

Последняя строка с её ×6,24 — не исключение, а следствие той же причины: в ней тоже есть распаковка словаря, и она одна даёт почти весь разрыв. Кортеж рядом с ней добавляет немного.

Причина — в том, как устроен быстрый протокол вызова. В его описании сказано, в каком виде вызываемый объект получает аргументы:

А имена этих аргументов едут отдельно:

Позиционные аргументы уже лежат массивом — их можно передать как есть. Словарь не лежит ни массивом значений, ни кортежем имён, и его приходится разобрать на то и другое. Отсюда и пятикратная разница: дело не в том, сколько значений передаётся, а в том, что одну структуру приходится превращать в две другие. Байт-код этой формы прогон не разбирает: объяснение взято из описания протокола, а как эти сто наносекунд раскладываются по шагам, замер не показывает.

И сразу о том, где эта кратность верна. Все числа сняты на пустой функции, так что это отношение одних накладных расходов к другим. Те же формы передачи на функции с телом из пятидесяти витков арифметики сняты отдельным прогоном — bench/calls/forms.py, блок 3:

Механизм тот же, кратность другая: ×1,06 против ×5,17 на пустой функции. Эти два числа из разных прогонов, и сравниваются здесь не они, а кратности внутри каждого. Из этого замера переносится не коэффициент, а то, какая форма передачи дороже остальных, и вывод: избегать её имеет смысл там, где тело функции сравнимо с накладными расходами на вызов.

Часть II. Ячейки

Замыкание держит не значение, а коробку

«Функция помнит окружение» — объяснение, из которого не выводится ничего из того, что видно на практике. А общая переменная у двух функций, три одинаковых ответа из цикла и nonlocal следуют из одного факта: переменная, которую видит вложенная функция, хранится в отдельном объекте — ячейке. Дальше она называется коробкой: важно в ней именно то, что значение лежит в ней, а не в самой функции.

Сказать «лежит не в кадре» было бы неточно, и неточность тут важная. Ссылка на ячейку как раз в кадре и есть: локальные переменные кадра держат ссылки на ячейки, а инструкции LOAD_DEREF и STORE_DEREF работают через них. Ячейка стоит не вместо кадра, а между кадром и значением, и именно поэтому одну и ту же ячейку могут держать сразу несколько замыканий, а живёт она дольше кадра, в котором появилась.

Ячейка — не деталь реализации CPython, а часть модели данных, и описана она прямо:

«Для каждой такой переменной» — в этом всё дело. Ячейка заводится на переменную, а не на функцию и не на вызов.

Две функции, одна коробка

Прогон bench/calls/cells.py, блок 2:

Ни одна из двух функций ничего другой не передавала. Они просто ссылаются на один и тот же объект, и is это подтверждает. Вот что такое «общая переменная» на самом деле — не магия области видимости, а разделяемый объект.

Почему цикл выдаёт три одинаковые функции

Отсюда же и классическая неожиданность:

[lambda: i for i in range(3)]        # [2, 2, 2]
[lambda i=i: i for i in range(3)]    # [0, 1, 2]

bench/calls/cells.py, блок 3, считает ячейки, и это отвечает на вопрос лучше любого объяснения: у первых трёх функций ячейка одна, у вторых трёх её нет вовсе.

Первая строка — не ошибка Python и не отдельное правило «позднее связывание». Ячейка заводится на переменную, переменная в цикле одна, и к моменту вызова в ней лежит последнее значение. Вторая строка не «чинит связывание», а избавляет от нужды в общей коробке: значение попадает в аргумент по умолчанию, а он вычисляется в момент создания функции — по разу на каждую.

Кто решает, что переменная станет ячейкой

Решает компилятор, один раз, и по коду видно, какое решение принято, — bench/calls/cells.py, блок 4:

box не попал в co_varnames, хотя присваивается в outer: компилятор увидел, что его берёт вложенная функция, и перевёл его в ячейку. Инструкции печатает тот же bench/calls/cells.py:

По ним видно всю цепочку: MAKE_CELL заводит коробку при входе в outer, STORE_DEREF кладёт в неё значение, COPY_FREE_VARS отдаёт ту же коробку в inner, LOAD_DEREF достаёт из неё значение. Ни на одном шаге значение не копируется.

Зачем коробка вообще нужна и при чём тут nonlocal

Кадр функции живёт до возврата, а коробка — дольше. Прогон bench/calls/cells.py, блок 5:

Вот отсюда и берётся nonlocal. Обычное присваивание в функции — это запись в кадр, и компилятор решает, куда писать, по одному правилу: имя, которому в теле что-то присваивают, считается локальным. Вложенной функции этого мало: ей надо писать не в свой кадр, а в коробку, общую с объемлющей функцией. nonlocal не «разрешает изменять внешнюю переменную» — он говорит компилятору, что имя не локальное, и присваивание должно стать STORE_DEREF.

Во что обходится чтение из ячейки

Последний вопрос, который здесь стоит закрыть: «замыкания медленные»? Каждое имя в этом замере читается внутри функции, поэтому в число входит и вызов; в последней колонке пустой вызов вычтен, то есть это само чтение. Это уже другой прогон — bench/calls/cost.py, блок 5:

Три разные инструкции чтения дали 3,96, 3,91 и 3,78 наносекунды — то есть различаются меньше чем на пять процентов, и каждая — примерно четверть пустого вызова. Платят не за чтение из ячейки, а за то, что вообще делается вызов.

Часть III. Практика

def make():
  out = []
  for i in range(3):
      out.append(lambda: i)
  return out


def make_bound():
  out = []
  for i in range(3):
      out.append(lambda i=i: i)
  return out


class C:
  def m(self):
      return 1


o = C()

print([f() for f in make()])
print([f() for f in make_bound()])
print(o.m is o.m, o.m == o.m)

[2, 2, 2]
[0, 1, 2]
False True

[0, 1, 2]
[0, 1, 2]
False True

[2, 2, 2]
[0, 1, 2]
True True

[2, 2, 2]
[2, 2, 2]
False True

Часть IV. Что из этого следует

Четыре вывода, которые держатся на замере

Не переписывать o.m() в bound = o.m. На быстром пути объект связанного метода не создаётся, экономить нечего, а такая правка его возвращает — и дешевле не становится: 18,34 против 17,74 наносекунды, причём разница лежит внутри разброса между раундами. Единственный случай, когда заранее связанный метод уместен, — когда его надо куда-то передать, и тогда речь не об экономии.

Не выбирать staticmethod ради скорости. При одинаковом способе чтения он медленнее обычного метода в полтора раза, а classmethod — почти втрое. Выбирать их стоит по смыслу: нужен ли методу экземпляр или класс.

Из звёздочек опасаться стоит только одной. f(**kwargs) на горячем пути с пустым телом стоит впятеро дороже прямой передачи; f(*args) — шестнадцать процентов, и о ней можно не думать. Кратность зависит от того, сколько работает сама функция: на теле из пятидесяти витков арифметики от пятикратной разницы остаётся шесть процентов. Смотреть надо не на коэффициент, а на то, сравнимо ли тело функции с ценой вызова.

Не бояться замыканий из-за цены. Чтение из ячейки неотличимо по времени от чтения локальной и глобальной переменной, и каждое — лишь доля цены вызова. Бояться в замыканиях стоит другого: ячейка одна на всех, кто видит переменную.

История версий

Чем измерено

Числа этой статьи получены этими скриптами. Каждый открывается прямо отсюда — вместе с записью прогона.

Время — две записи, обе на одной сборке:

• bench/calls/cost.py — пятнадцать форм вызова и три утверждения
• bench/calls/forms.py — матрица форм метода, разброс по раундам, звёздочки на непустой функции

Байт-код и объекты — сравнимы между версиями, записи на всех трёх:

• bench/calls/shapes.py
• bench/calls/cells.py

Числа для задач раздела «Практика»:

• bench/calls/practice.py

Python 3.12.3 (GCC 13.3.0), 3.13.7 (Clang 20.1.4), 3.14.7 (Clang 22.1.3); Intel Xeon 2,80 ГГц, 2 vCPU.

Границы у трёх видов утверждений статьи разные, и стоит их развести:

• Поведение — одинаково на всех трёх версиях: o.m без вызова создаёт объект метода, o.m is o.m даёт False, одна ячейка приходится на переменную. Проверено на 3.12.3, 3.13.7 и 3.14.7.
• Имена специализаций — свойство версии: на 3.12.3 специализация len называется CALL_NO_KW_LEN, на 3.13.7 и 3.14.7 — CALL_LEN. Это свойства кода, и сравнивать их между версиями можно.
• Время — только 3.13.7 с включённым GIL, и только внутри каждого из двух прогонов по отдельности. Между версиями оно не сравнивается вовсе: у сборок разные компиляторы и разные флаги. Свободнопоточные сборки здесь не мерились.