On Jul 26, 2019, at 15:05, Kyle Stanley <aeros167@gmail.com> wrote:
Andrew Barnert wrote:
consume(print(item) for item in lst)
From my understanding, consume() effectively provides the functionality the author was looking for.
Exactly. And it’s readable and concise, and there’s even an implementation in the docs if you don’t think of it yourself.
Also, between the options of `for _ in iter:` vs `colllections.deque(it, maxlen=0)`, how significant is the performance difference?
I had assumed that the performance of `for _ in iter` would be significantly better, since due to the overhead cost of creating and filling a double ended queue, which provides optimization for insertion at the beginning and end. Wouldn't a one directional iterator provide better performance and have a lower memory cost if there is no modification required?
The maxlen of 0 means after determining that 0+1 > 0, the (C) function returns without even getting to the array manipulation stuff. Consuming the iterator in a for loop does even less work inside the loop, but it means the loop is in Python rather than C, which is a lot more expensive than the INC and JNZ that you save. You’re right that it probably rarely makes a difference, but for something that’s going to be recommended in the official docs and potentially used in who-knows-what code, apparently someone thought it was worth the effort to benchmark. I don’t know if anyone has retested this recently, but there was a StackOverflow question maybe 5 years back asking why itertools did this instead of something faster, and IIRC, after testing every idea everyone had an a variety of platforms and versions, the conclusion was that deque was (still) by far the fastest way to do it in CPython (short of a custom C function for consume, and even that isn’t much faster), and not quite the fastest but close enough in PyPy.