Speed of Nested Functions & Lambda Expressions

[beginner]

Hi All,

It is really convenient to use nested functions and lambda
expressions. What I'd like to know is if Python compiles fn_inner()
only once and change the binding of v every time fn_outer() is called
or if Python compile and generate a new function object every time. If
it is the latter, will there be a huge performance hit? Would someone
give some hint about how exactly Python does this internally?

def fn_outer(v):
a=v*2
def fn_inner():
print "V:%d,%d" % (v,a)

fn_inner()

Thanks,
Geoffrey

 

[Gary Herron]

Hi All,

It is really convenient to use nested functions and lambda
expressions. What I'd like to know is if Python compiles fn_inner()
only once and change the binding of v every time fn_outer() is called
or if Python compile and generate a new function object every time. If
it is the latter, will there be a huge performance hit? Would someone
give some hint about how exactly Python does this internally?

def fn_outer(v):
a=v*2
def fn_inner():
print "V:%d,%d" % (v,a)

fn_inner()

Thanks,
Geoffrey

The code is compiled only once when the file is initially read in.
During execution of fn_outer, v will be bound to a value, then a, then
fn_inner will be bound (to an already compiled code object) and so on.

Really, from the point of view of Python while executing fn_outer, the
def of fn_inner looks just like an assignment with fn_inner as the
variable name and a code object as the value.

Gary Herron

 

[beginner]

The code is compiled only once when the file is initially read in.
During execution of fn_outer, v will be bound to a value, then a, then
fn_inner will be bound (to an already compiled code object) and so on.

Really, from the point of view of Python while executing fn_outer, the
def of fn_inner looks just like an assignment with fn_inner as the
variable name and a code object as the value.

Gary Herron- Hide quoted text -

- Show quoted text -

I see. Thanks Gary!

 

[Terry Reedy]

| beginner wrote:
| > Hi All,
| >
| > It is really convenient to use nested functions and lambda
| > expressions. What I'd like to know is if Python compiles fn_inner()
| > only once and change the binding of v every time fn_outer() is called
| > or if Python compile and generate a new function object every time. If
| > it is the latter, will there be a huge performance hit? Would someone
| > give some hint about how exactly Python does this internally?

Python the language does not 'do' anything. The details could be
implementation specific.

| > def fn_outer(v):
| > a=v*2
| > def fn_inner():
| > print "V:%d,%d" % (v,a)
| >
| > fn_inner()
| >
| > Thanks,
| > Geoffrey
| >
| >
| The code is compiled only once when the file is initially read in.
| During execution of fn_outer, v will be bound to a value, then a, then
| fn_inner will be bound (to an already compiled code object) and so on.

In CPython, I believe, fn_inner is bound to a *new* *function* object, not
the once-compiled code object. It has to be a new object because fn_outer
could return the inner function, as is not uncommon. And function objects
are somewhat mutable. And each returned function might have different
values of enclosed outer variables. However, each function object has the
same .func_code member.
def inner(m):
return n+m
return inner
<type 'function'>

| Really, from the point of view of Python while executing fn_outer, the
| def of fn_inner looks just like an assignment with fn_inner as the
| variable name and a code object as the value.

Again, the value is a function object.

Terry Jan Reedy

 

[Duncan Booth]

It is really convenient to use nested functions and lambda
expressions. What I'd like to know is if Python compiles fn_inner()
only once and change the binding of v every time fn_outer() is called
or if Python compile and generate a new function object every time. If
it is the latter, will there be a huge performance hit? Would someone
give some hint about how exactly Python does this internally?

You can use Python's bytecode disassembler to see what actually gets
executed here:
a=v*2
def fn_inner():
print "V:%d,%d" % (v,a)

fn_inner()

2 0 LOAD_DEREF 1 (v)
3 LOAD_CONST 1 (2)
6 BINARY_MULTIPLY
7 STORE_DEREF 0 (a)

3 10 LOAD_CLOSURE 0 (a)
13 LOAD_CLOSURE 1 (v)
16 BUILD_TUPLE 2
19 LOAD_CONST 2 (<code object fn_inner at
01177218, file "<pyshell#3>", line 3>)
22 MAKE_CLOSURE 0
25 STORE_FAST 1 (fn_inner)

6 28 LOAD_FAST 1 (fn_inner)
31 CALL_FUNCTION 0
34 POP_TOP
35 LOAD_CONST 0 (None)
38 RETURN_VALUE
When you execute the 'def' statement, the two scoped variables a and v
are built into a tuple on the stack, the compiled code object for the
inner function is also pushed onto the stack and then the function is
created by the 'MAKE_CLOSURE' instruction. This is then stored in a
local variable (STORE_FAST) which is then loaded and called.

So the function definition is pretty fast, BUT notice how fn_inner is
referenced by STORE_FAST/LOAD_FAST whereas a and v are referenced by
LOAD_DEREF/STORE_DEREF and LOAD_CLOSURE.

The code for fn_inner also uses LOAD_DEREF to get at the scoped
variables:

4 0 LOAD_CONST 1 ('V:%d,%d')
3 LOAD_DEREF 1 (v)
6 LOAD_DEREF 0 (a)
9 BUILD_TUPLE 2
12 BINARY_MODULO
13 PRINT_ITEM
14 PRINT_NEWLINE
15 LOAD_CONST 0 (None)
18 RETURN_VALUE

(its a bit harder to disassemble that one, I stuck a call to dis.dis
inside fn_outer to get that)

If you do some timings you'll find that LOAD_DEREF/STORE_DEREF are
rather slower than LOAD_FAST/STORE_FAST, so while the overhead for
creating the function is minimal you could find that if you access the
variables a lot (even in fn_outer) there may be a measurable slow-down.

If timings show that it is a code hotspot then you might find it better
to nest the function but pass any required values in as parameters (but
if you don't have evidence for this just write whatever is clearest).

 

[beginner]

You can use Python's bytecode disassembler to see what actually gets
executed here:


a=v*2
def fn_inner():
print "V:%d,%d" % (v,a)

fn_inner()


2 0 LOAD_DEREF 1 (v)
3 LOAD_CONST 1 (2)
6 BINARY_MULTIPLY
7 STORE_DEREF 0 (a)

3 10 LOAD_CLOSURE 0 (a)
13 LOAD_CLOSURE 1 (v)
16 BUILD_TUPLE 2
19 LOAD_CONST 2 (<code object fn_inner at
01177218, file "<pyshell#3>", line 3>)
22 MAKE_CLOSURE 0
25 STORE_FAST 1 (fn_inner)

6 28 LOAD_FAST 1 (fn_inner)
31 CALL_FUNCTION 0
34 POP_TOP
35 LOAD_CONST 0 (None)
38 RETURN_VALUE



When you execute the 'def' statement, the two scoped variables a and v
are built into a tuple on the stack, the compiled code object for the
inner function is also pushed onto the stack and then the function is
created by the 'MAKE_CLOSURE' instruction. This is then stored in a
local variable (STORE_FAST) which is then loaded and called.

So the function definition is pretty fast, BUT notice how fn_inner is
referenced by STORE_FAST/LOAD_FAST whereas a and v are referenced by
LOAD_DEREF/STORE_DEREF and LOAD_CLOSURE.

The code for fn_inner also uses LOAD_DEREF to get at the scoped
variables:

4 0 LOAD_CONST 1 ('V:%d,%d')
3 LOAD_DEREF 1 (v)
6 LOAD_DEREF 0 (a)
9 BUILD_TUPLE 2
12 BINARY_MODULO
13 PRINT_ITEM
14 PRINT_NEWLINE
15 LOAD_CONST 0 (None)
18 RETURN_VALUE

(its a bit harder to disassemble that one, I stuck a call to dis.dis
inside fn_outer to get that)

If you do some timings you'll find that LOAD_DEREF/STORE_DEREF are
rather slower than LOAD_FAST/STORE_FAST, so while the overhead for
creating the function is minimal you could find that if you access the
variables a lot (even in fn_outer) there may be a measurable slow-down.

If timings show that it is a code hotspot then you might find it better
to nest the function but pass any required values in as parameters (but
if you don't have evidence for this just write whatever is clearest).

Thanks for the detailed analysis, Duncan. Also thanks for showing how
the disassembler can be used to figure this out. I was just looking
for a tool like this. This is great. Thanks again.