That is a fair point. Perhaps I got too carried away by analyzing the raw performance that I forgot what kinds of things need to happen behind the scenes. Howev

That is a fair point. Perhaps I got too carried away by analyzing the raw performance that I forgot what kinds of things need to happen behind the scenes. However, I imagine that the type checking has to be done by reduce as well as within a loop. Reduce is probably faster because the underlying native C function can iterate over a vector faster than the bytecode-compiled for loop, and since you're passing a builtin to it, it doesn't ever need to leave the native realm until it returns from reduce. If the for loop wasn't JIT'ed, I'd understand why this is slower. What about PyPy? How about trying the code on that? Maybe it will be smart enough to compile the for loop into native code that is equivalent to the reduce builtin. I'm really curious about what happens under the hood here...