Steven D'Aprano wrote: > On Sat, 25 Jun 2005 21:30:26 +0200, Peter Otten wrote: > >> Mandus wrote: >> >>> By using the builtin reduce, I >>> move the for-loop into the c-code which performs better. >> >> No. There is no hope of ever writing fast code when you do not actually >> measure its performance. > > Good grief! You've been spying on Mandus! How else could you possibly know > that he doesn't measure performance? Are you running a key-logger on his > machine? *wink*
His mentioning reduce() as a performance panacea was a strong indication even without looking over his shoulders. He filled in some conditions in a later post, but "[U]sing reduce ... performs better [than a for-loop]" is just wrong. > For the record, perhaps now is a good time to mention that even Guido > recommended the use of map, filter and reduce in some circumstances: Personally I wouldn't rely on authority when I can measure without much hassle. And the lesson I take from Guido's essay is rather how he got to his conclusions than what his actual findings were. After all, Python may have advanced a bit since he wrote the text. > Do we really need to profile our code every single time to know this? No. Only if we care about the performance of a particular piece. And if we do we are sometimes in for a surprise. > Isn't it reasonable to just say, "I use join because it is faster than > adding strings" without being abused for invalid optimization? OK, I am making a guess: "".join(strings) is more often faster than naive string addition than reduce() wins over a for-loop. I don't think my pointed comment qualifies as "abuse", by the way. Peter -- http://mail.python.org/mailman/listinfo/python-list