Generator vs functools.partial?

[John O'Hagan]

Sometimes a function gets called repeatedly with the same expensive argument:

def some_func(arg, i):
(do_something with arg and i)

same_old_arg = big_calculation()
for i in lots_of_items:
some_func(same_old_arg, i)

A simple case like that looks OK, but it can get messy when groups of arguments
are passed between functions, especially if the arguments are used by functions
called within the functions they are passed to (by other functions!).

Maybe that's a code smell, but it can be cleaned up with:

import functools
some_func = functools.partial(some_func, big_calculation())
for i in lots_of_items:
some_func(i)

But what about a generator?

def some_func():
arg = big_calculation()
while 1:
i = yield
(do_something with arg and i)

some_gen = some_func()
some_gen.send(None)
for i in lots_of_items:
some_gen.send(i)

I like this because it encapsulates the calculation of the arguments
inside the function that is using them without repeating it, and there are no
restrictions on argument order like partial. But sending None is annoying.

Old news? Thoughts, criticisms, theories?

 

[Steven D'Aprano]

Sometimes a function gets called repeatedly with the same expensive
argument:

def some_func(arg, i):
(do_something with arg and i)

same_old_arg = big_calculation()

Since big_calculation() is only called once, the cost of generating that
expensive argument is only paid once.

for i in lots_of_items:
some_func(same_old_arg, i)

Passing that same_old_arg to some_func is cheap. Once you've paid the
cost of producing the value in the first place, there is absolutely no
difference in cost between passing an "expensive" argument and a "cheap"
argument.

A simple case like that looks OK, but it can get messy when groups of
arguments are passed between functions, especially if the arguments are
used by functions called within the functions they are passed to (by
other functions!).

I'm not sure what you're trying to say here. Argument passing is cheap.
Function call overhead is not quite so cheap, but unless you've carefully
profiled your code and determined that the cost of function overhead is
significant, you're better off using ignoring it. Likely the actual
calculation within the function is hundreds or thousands of times more
expensive than the function call itself.

Maybe that's a code smell, but it can be cleaned up with:

import functools
some_func = functools.partial(some_func, big_calculation())
for i in lots_of_items:
some_func(i)

Have you actually measured this to see whether it *actually is* faster,
or are you just assuming it will be faster?

I expect that at best it will be no faster at all, and quite possibly
slightly slower. The main reason is that instead of one function call
(calling some_func directly with two arguments) you now have two (partial
function called with one argument, which internally calls some_func with
two). Possibly that internal call is implemented in C and may be a little
faster than if it were implemented in Python bytecode, but still, two
calls can't be faster than one.


[...]

Old news? Thoughts, criticisms, theories?

Premature optimization is the root of all evil.

 

[Thomas Rachel]

Am 21.06.2012 13:25 schrieb John O'Hagan:

But what about a generator?

Yes, but...

def some_func():
arg = big_calculation()
while 1:
i = yield
(do_something with arg and i)

some_gen = some_func()
some_gen.send(None)
for i in lots_of_items:
some_gen.send(i)

rather

def some_func(it):
arg = big_calculation()
for i in it:
do_something(arg, i)

some_func(lots_of_items)


HTH,

Thomas

 

[John O'Hagan]

Since big_calculation() is only called once, the cost of generating that
expensive argument is only paid once.


Passing that same_old_arg to some_func is cheap. Once you've paid the
cost of producing the value in the first place, there is absolutely no
difference in cost between passing an "expensive" argument and a "cheap"
argument.



I'm not sure what you're trying to say here. Argument passing is cheap.
Function call overhead is not quite so cheap, but unless you've carefully
profiled your code and determined that the cost of function overhead is
significant, you're better off using ignoring it. Likely the actual
calculation within the function is hundreds or thousands of times more
expensive than the function call itself.

[...]

What I neglected to say was that I'm looking to refactor for clarity and DRY
to minimise the number of objects that get passed through a chain of functions
before being used, rather than efficiency. I realise the different examples I
gave (and the more obvious one in Thomas's reply) do more or less the same
thing and that there would probably only be marginal efficiency differences.
I'll try to come up with better examples to show what I mean. Or not: see my
reply to Thomas.

Premature optimization is the root of all evil.

100% agreement.

Thanks,

 

[John O'Hagan]

Am 21.06.2012 13:25 schrieb John O'Hagan:


Yes, but...


rather

def some_func(it):
arg = big_calculation()
for i in it:
do_something(arg, i)

some_func(lots_of_items)

Ah yes, this demonstrates that my examples were too simple to show what I'm
trying to do. In my real code, several functions take the elements from an
iterator, so I can't pass the whole iterator to each one. I have a feeling there
is some bad factoring in my real code which will disappear if I manage to
provide a clear example, which I'll now endevour to do. Thanks for the reply.