This is relating to the following: (In Python Code)
for i in object:
doSomething(i)
versus
map(doSomething, object)
Both are easy to understand, and short, but is there any speed difference? Now, if doSomething had a return value we needed to check it would be returned as a list from map, and in the for loop we could either create our own list or check one at a time.
for i in object:
returnValue = doSomething(i)
doSomethingWithReturnValue(returnValue)
versus
returnValue = map(doSomething, object)
map(doSomethingWithReturnValue, returnValue)
Now, I feel the two diverge a little bit. The two doSomethingWithReturnValue functions may be different based on if checking them on the fly as we go through the loop or if checking them all at once at the end produce different results. Also it seems the for loop would always work, maybe slower, where the map would only work under certain scenarios. Of course, we could make contortions to make either work, but the whole point is to avoid this type of work.
What I’m looking for is a scenario where the mapping function truly shines in comparison to a well done for loop in performance, readability, maintainability, or speed of implementation. If the answer is there really isn’t a big difference then I’d like to know when in practice people use one or the other or if it’s really completely arbitrary and set by coding standards depending on your institution.
Thanks!
mapis useful when you want to apply the function to every item of an iterable and return a list of the results. This is simpler and more concise than using a for loop and constructing a list.foris often more readable for other situations, and in lisp there were lots of iteration constructs that were written basically using macros and map. So, in cases wheremapdoesn’t fit, use aforloop.In theory, if we had a compiler/interpreter that was smart enough to make use of multiple cpus/processors, then
mapcould be implemented faster as the different operations on each item could be done in parallel. I don’t think this is the case at present, however.