Calling a function: what it costs, what does not happen, and where cells live

What a call costs

Almost every number was taken on a call to an empty function: the body does nothing, so only what happens around it is measured. Two rows are there for scale: p.x — reading a slot, with no call in it at all — and len_(data), a C function.

Numbers from bench/calls/cost.py, one run of 3.13.7; they may be compared only with one another.

Why a method barely costs more than a function

By the data model o.m creates a bound-method object, and the call ought to cost more. On the fast path that object does not exist at all: the interpreter sees that a call follows the attribute read immediately and puts the function and the instance on the stack separately. No bound method is built at all.

That the object really is created when asked for without a call takes one line to see:

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

Hence the advice best not followed: bound = o.m brings the object back and the call starts going through it — 18.34 against 17.74 nanoseconds: no cheaper, and that it is more expensive the measurement does not prove, the difference being smaller than the round-to-round spread.

Star-args

One form out of five is expensive: f3(**kwargs) costs five times direct passing. f3(*args) costs only sixteen per cent more.

The reason is that positional arguments and the values of keyword arguments travel in an array while the names of the keyword arguments travel in a separate tuple. Positional arguments already lie the way they are needed and are handed over as they are; a dict lies neither way and has to be taken apart into an array of values and a tuple of names. The cost is not in how many values are passed but in having to turn one structure into two others.

Where a closure's variable lives

A closure holds not a value but a cell — a separate object, visible from Python as an element of __closure__. Everything else follows from that.

Two functions created side by side refer to the same cell, and increment.__closure__[0] is read.__closure__[0] gives True. Neither passed the other anything: they simply look into one box — one cell object, shared.

Three lambdas from a loop share one cell too — because a cell is made per VARIABLE, and the loop has one variable. By the time they are called it holds the last value, hence [2, 2, 2]. This is not a special rule about loops, nor a bug.

Writing lambda i=i: i does not "fix the binding" but removes the need for a shared box: those functions have an empty __closure__, and the value was computed when each was created.

There is no reason to fear closures for their speed: reading from a cell costs 3.91 nanoseconds against 3.96 for a local variable and 3.78 for a global — all three indistinguishable, and all three a fraction of an empty call.

What to do with this

Do not rewrite o.m() as bound = o.m for speed. Do not pick staticmethod and classmethod by speed — only by meaning. Of the stars, beware **kwargs on a hot path. And keep the cell in mind: it is ONE for everyone who sees the variable, and that is what deserves attention in closures.

Three claims about the cost of a call travel together, and one measurement checks all of them: "calling a method costs more than calling a function", "binding a method in advance is cheaper than going through the dot every time", "staticmethod is faster than an ordinary method — it has no self".

The measurement barely supports the first. It contradicts the second and the third, and the second in the opposite direction.

All three have the same explanation, and it is not about nanoseconds: on the fast path of a method call, the bound-method object IS NOT CREATED. There is nothing to save on its creation, and whoever "optimises" the call by binding the method in advance brings the object back.

The second half of the article is about closures, and it is not here by coincidence. A cell is where the variable a nested function sees actually lives, and how it works explains the rest: the variable two functions share, the three identical answers from a loop, and why nonlocal exists.

Part I. The cost of a call

What is being measured

Every number was taken on a call to an EMPTY function: the body does nothing, so only what happens around the body is measured. Beside it stands a line with no call at all — reading an attribute on an object with __slots__, the cheapest read there is — to give the nanoseconds a scale. Measured on 3.13.7 with bench/calls/cost.py:

Read it this way: an empty call on this machine is about fifteen nanoseconds — roughly twice the cheapest attribute read available here. That is a comparison of scale between two different operations, not a decomposition of the cost of a call: what those fifteen nanoseconds are made of is not something this measurement says at all. Everything else in the table is a surcharge for the form.

The three claims and what became of them

From the same run:

The first barely holds: sixteen per cent is not a reason to rewrite anything, and it is less than the gap between f1(1) and f1(a=1) in the same table: 16.65 against 25.39.

The second does not hold either: a method bound in advance is at any rate no cheaper. That it is MORE EXPENSIVE is not something these two numbers prove, and why is taken up below, in a section of its own about spread.

The third is contradicted in the other direction: staticmethod is slower than an ordinary method and classmethod noticeably slower than both. But that comparison changes two things at once, so below it is separated by axis.

First — what is being compared with what

The third row puts o.m() next to C.s(), and TWO things differ between those two spellings: the kind of method and what it is read through — the instance or the class. While both axes are mixed, the difference cannot be attributed to the kind of method: it could have come from reading through the class.

So both axes are separated by a run of their own, in which all six forms were taken together — bench/calls/forms.py, block 1:

Now each comparison changes exactly one thing. With the reading held fixed — through the instance — staticmethod costs ×1.54 of an ordinary method and classmethod ×2.72. The way of reading, with the kind of method held fixed, adds ×1.07 and ×1.09 — a few per cent.

Separating the axes did not overturn the conclusion: staticmethod really is more expensive than an ordinary method, and it is the kind of method that does it, not the reading through the class. But that can only be said now.

Why: what exactly does not happen

The answer to all three at once is in the bytecode. bench/calls/shapes.py disassembles these forms after two hundred warm-up calls each:

Look at the o.m(t) row and the last one. The attribute-reading instruction is DIFFERENT: LOAD_ATTR_METHOD_WITH_VALUES when a call follows immediately, and a plain LOAD_ATTR when it does not.

The difference is in what goes on the stack. On the path with a call, the function and the instance go there separately: there is nothing to bind them into, and no bound-method object is created. On the path without a call it is created, because it was asked for.

That it really is created when asked for needs no bytecode to check:

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

Two consecutive reads give two DIFFERENT objects. That work is exactly what the fast path does not do.

The third claim is visible in the same table. C.s(t) takes three instructions rather than two: the class name is read first, then the attribute on it, and there is no specialisation on the instance at all. That is the "way of reading" axis, to which the matrix above assigns ×1.07; the rest of the ×1.57 is the kind of method, ×1.54 with the reading held fixed through the instance. This run does not disassemble o.s(t), so the split comes from time rather than from instructions. C.c(t) has the same extra attribute read and calls through a bound method on top of it: CALL_BOUND_METHOD_EXACT_ARGS. What each of the two additions costs on its own, this measurement does not separate — only the total is visible, 46.89 against 27.88.

Hence the second claim as well. Binding a method in advance means creating a PyMethodObject once and calling through it: CALL_BOUND_METHOD_EXACT_ARGS. There is nothing to save — the fast path never created that object — while a level of indirection remains.

The numbers, though, say less than one would like. 18.34 against 17.74 is three per cent, and before leaning on a difference that size one has to know the spread. It is printed by bench/calls/forms.py, block 2. The numbers there are its own — a different run, not comparable with the ones above; what has to be compared is the gap inside that run against its own spread:

The gap between bound() and o.m() is 1.28 ns against a spread of up to 2.24 ns within the rounds — that is LESS than the spread. So "a method bound in advance is slower" does NOT follow from these measurements: the two numbers lie inside their own noise. What does follow is that it is no cheaper, and that is exactly the conclusion practice needs: binding a method in advance for speed is not worth it, because there is no gain in any run. Binding in advance is for when the method has to be PASSED somewhere.

Star-args: one form out of five is expensive

"Stars are expensive" is one more durable habit, and it is right in exactly one case out of five (bench/calls/cost.py):

Unpacking a tuple is nearly free — sixteen per cent. Receiving into stars costs double, which is a fair price for an arbitrary signature. But unpacking a DICT when passing costs five times as much, and that is the one place worth thinking about.

The last row, at ×6.24, is not an exception but the same cause: it contains a dict unpack too, and that alone accounts for nearly the whole gap. The tuple beside it adds little.

The reason is in how the fast calling protocol is built. Its description says in what shape the callee receives the arguments:

And the names of those arguments travel separately:

Positional arguments already lie in an array: they can be handed over as they are. A dict lies neither in an array of values nor in a tuple of names, and it has to be taken apart into both. Hence the fivefold gap — the cost is not in how many values are passed but in having to turn one structure into two others. The run does not disassemble this form: the explanation comes from the description of the protocol, and how those hundred nanoseconds break down step by step the measurement does not show.

And straight away about the bounds of that ratio. All the numbers were taken on an EMPTY function, which makes it a ratio of overhead to overhead. The same thing on a function with a body was taken by a separate run — bench/calls/forms.py, block 3:

Same mechanism, different ratio: ×1.06 against ×5.17 on the empty function. Those two numbers come from different runs, and what is compared here is not them but the ratios inside each. What carries over from this measurement is not the coefficient but WHICH form of passing is the expensive one — and the fact that avoiding it makes sense where the body of the function is comparable to the overhead of the call.

Part II. Cells

A closure holds a box, not a value

"A function remembers its environment" is an explanation from which none of the observable behaviour follows. All of it follows from one fact: the variable a nested function sees is stored THROUGH A SEPARATE OBJECT — a cell. From here on it is called a box, because that is the part of it that matters: the value sits in the box, not in the function itself.

Saying "it does not live in the frame" would be inaccurate, and the inaccuracy matters. The reference to the cell is in the frame: a frame's local variables hold references to cells, and the LOAD_DEREF and STORE_DEREF instructions work through them. The separate object is not instead of the frame but between the frame and the value — which is exactly why several closures can hold the same cell, and why it outlives the frame it appeared in.

A cell is not a CPython implementation detail but part of the data model, and it is described directly:

"For each such VARIABLE" is the whole thing. A cell is made per variable, not per function and not per call.

Two functions, one box

From bench/calls/cells.py — identical on 3.12.3, 3.13.7 and 3.14.7:

Neither function passed the other anything. They simply refer to the same object, and is confirms it. That is what a "shared variable" actually is — not scoping magic but a shared object.

Why a loop yields three identical functions

The classic surprise comes from the same place:

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

The run counts the cells, and that answers the question better than any explanation: the first three functions share ONE cell, the second three have none at all.

The first line is not a Python bug, nor a separate rule called "late binding". A cell is made per variable, the loop has one variable, and by the time the lambdas are called it holds the last value. The second line does not "fix the binding" — it removes the need for a shared box: the value goes into a default argument, and that is computed when each function is CREATED.

Who decides that a variable becomes a cell

The compiler decides, once, and the decision is visible in the code (bench/calls/cells.py):

box is assigned in outer, yet it is not in co_varnames: the compiler saw that a nested function takes it and moved it into a cell. The rest of the chain is visible in the instructions the same run prints:

MAKE_CELL creates the box on entry to outer, STORE_DEREF puts the value in, COPY_FREE_VARS hands the same box to inner, LOAD_DEREF takes the value out. At no step is the value copied.

Why a box is needed at all, and where nonlocal comes in

A function's frame lives until it returns; the box lives longer. That is what bench/calls/cells.py, block 5, shows:

That is where nonlocal comes from. An ordinary assignment inside a function is a write into the frame, and the compiler decides where to write by one rule: a name assigned anywhere in the body is local. For a nested function that is not enough — it has to write not into its own frame but into the box shared with the enclosing function. nonlocal does not "permit changing an outer variable"; it tells the compiler the name is not local, so the assignment must become STORE_DEREF.

What reading from a cell costs

One question remains: are closures slow? Each name below is read INSIDE a function, so the call is in the number; the second column has the empty call subtracted (bench/calls/cost.py):

The three reading instructions came out at 3.96, 3.91 and 3.78 nanoseconds — less than five per cent apart, and each about a quarter of an empty call. What is paid for is not reading from a cell but making a call at all.

Part III. Practice

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

Part IV. What follows

Four conclusions the measurements support

Do not rewrite o.m() as bound = o.m. No bound-method object is created on the fast path, so there is nothing to save, and such an edit brings it back — and it is no cheaper either: the 18.34 against 17.74 nanoseconds lies inside the round-to-round spread. The one case where binding in advance is right is when the method has to be PASSED somewhere, and then it is not about saving anything.

Do not pick staticmethod for speed. With the way of reading held fixed it is one and a half times slower than an ordinary method, and classmethod nearly three times slower. Pick them by meaning: does the method need the instance or the class.

Only one star form is worth avoiding. f(**kwargs) on a hot path with an empty body costs five times what direct passing costs; f(*args) costs sixteen per cent and needs no thought. The ratio is tied to how much the function itself does: on a body of fifty rounds of arithmetic, six per cent is all that is left of the fivefold gap. What to look at is not the coefficient but whether the body of the function is comparable to the cost of the call.

Do not fear closures over their cost. Reading from a cell is indistinguishable in time from reading a local or a global name, and all three are a fraction of a call. What is worth fearing in closures is something else: that the cell is ONE for everyone who sees the variable.

Version history

How this was measured

The numbers in this article come from these scripts. Each opens from here, together with the record of its run.

Time — two records, both on one build:

• bench/calls/cost.py — fifteen call forms and the three claims
• bench/calls/forms.py — the matrix of method forms, the round-to-round spread, and star-args on a non-empty function

Bytecode and objects — comparable across versions, recorded on all three:

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

The basis for the exercises in "Practice":

• 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 GHz, 2 vCPU.

The three kinds of claim in this article have different bounds, and they are worth separating:

• Behaviour — the same on all three versions: o.m without a call creates a method object, o.m is o.m gives False, one cell goes per variable. Checked on 3.12.3, 3.13.7 and 3.14.7.
• Specialisation names — a property of the version: on 3.12.3 the len specialisation is called CALL_NO_KW_LEN, on 3.13.7 and 3.14.7 CALL_LEN. Those are properties of code and may be compared across versions.
• Time — 3.13.7 with the GIL enabled only, and only within each of the two runs separately. It is never compared across versions: the builds have different compilers and different flags. Free-threaded builds were not measured here.