Performance of list comprehensions vs. map
Paul Winkler
slinkp23 at yahoo.com
Wed Sep 12 11:46:03 EDT 2001
More information about the Python-list mailing list
Wed Sep 12 11:46:03 EDT 2001
- Previous message (by thread): Performance of list comprehensions vs. map
- Next message (by thread): Stackless Python and Python 2.x
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Previous message (by thread): Performance of list comprehensions vs. map
- Next message (by thread): Stackless Python and Python 2.x
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list