Performance of list comprehensions vs. map

[Paul Winkler]

On 7 Sep 2001 20:49:29 GMT, Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
>Fri, 07 Sep 2001 20:17:12 GMT, Paul Winkler <slinkp23 at yahoo.com> pisze:
>
>> So for the foreseeable future, looks like map() is likely to remain
>> the fastest way to generate lists.
>
>As long as the function to map is ready. If a separate function must
>be created just for mapping (doesn't matter id by 'def' or 'lambda'),
>I would expect a list comprehension with the function's body inserted
>to be faster than map which must call it.

Interesting idea. I just tried ...  Yes, *if* what you're doing is
practical to inline in the list comprehension, that can beat map().
And of course if what you're doing is calling, say, a function or
method from the standard library, you're not going to inline that, so
map() still looks like a good idea.

Example:

test = xrange(100000)

def multiplier(x):
    return x * 0.99

def mapper(m=multiplier, f=test):
    return map(m, f)

def comprehender_inline(f=test):
    return [x * 0.99 for x in f]

def comprehender(m=multiplier, f=test):
    return [m(x) for x in f]

# end of example

In this case, comprehender_inline wins by a very large margin,
followed by mapper, which is in turn faster than comprehender.

But here's the counterexample:

import string
test = # a 100000-character random string

def mapper(m=string.upper, f=test):
    return map(m, f)

def comprehender(m=string.upper, f=test):
    return [m(x) for x in f]

su = string.upper
def comprehender_inline(f=test):
    su = string.upper
    return[su(x) for x in f]


# end example

In this case, comprehender_inline is about the same speed as
comprehender, no surprise since they're almost identical. Map wins by
a large margin. If you rewrite comprehender_inline so it returns
[x.upper() for x in f], it speeds up quite a lot, but still loses to
map, and we're not really comparing apples to apples anymore.