4 ms·
Point 3 is weakened by the fact that map can indeed be faster. http://codepad.org/SzXcubXy http://codepad.org/SzXcubXy -- in fact, point 2 and point 3 are in co
by devinj 16y ago
Point 3 is weakened by the fact that map can indeed be faster. http://codepad.org/SzXcubXy http://codepad.org/SzXcubXy -- in fact, point 2 and point 3 are in conflict, because map() does use a C-loop, whereas list comprehensions do not. As it turns out, point 2 was the correct one.
Also, and this is just on a more minor, pedantic note, list comprehensions basically are regular for loops, except with the use of the list-append opcode instead of a getattr-call pair. This produces a minor speedup, but it's nothing to write home about, honest. (using a different pastebin because it has a feature I needed): http://ideone.com/dT1LG http://ideone.com/dT1LG . The story is a bit different on 3.x, where list comps are implemented very differently: http://ideone.com/58FGZ http://ideone.com/58FGZ
- edanm 16y agoFirst off, I'm really no expert in Python or optimizations - I'm only reporting on observations. Having said that, I was pretty surprised that the list comprehensions ran faster than map, exactly because of point 2 - I had assumed that map used a c-loop, whereas list comprehensions did not. Unfortunately, I don't have that code sitting around anywhere so I can't redo the tests - I just remember being very surprised by those results.
- deathflute 16y agoIn my experience edanm is correct. map/reduce/filter are faster with built-in functions, but list comprehensions are faster with user-defined ones For eg. using python 2.5.2 In [9]: l = ['10'] * 5000000 In [10]: timeit -n5 map(int, l) 5 loops, best of 3: 1.29 s per loop In [11]: timeit -n5 [int(i) for i in l] 5 loops, best of 3: 1.64 s per loop
- devinj 16y agoYou mean "incorrect". Also, I did post detailed timing results above.