Generator vs List comprehension optimzations

[Marius-Juston]

Feature or enhancement

Proposal:

I don't know if it's possible but it might be a good idea to look at optimizations for the generator function used inline for a function call

func( a for a in range(N))

vs it's list comprehension counterpart

func([ a for a in range(N)])

for example, which I feel is a pretty common syntax; however, due to some overheads (I think?) using a list comprehension is just faster (as per benchmarks on builtin functions)

Benchmark	gen	list
min: 1	344 ns	238 ns: 1.44x faster
min: 10	649 ns	414 ns: 1.57x faster
min: 100	3.27 us	2.17 us: 1.51x faster
min: 1000	33.3 us	25.5 us: 1.31x faster
min: 10000	335 us	268 us: 1.25x faster
min: 1000000	34.5 ms	41.3 ms: 1.20x slower
min: 10000000	338 ms	438 ms: 1.30x slower
max: 1	342 ns	239 ns: 1.43x faster
max: 10	645 ns	412 ns: 1.57x faster
max: 100	3.28 us	2.15 us: 1.52x faster
max: 1000	33.2 us	25.3 us: 1.31x faster
max: 10000	346 us	273 us: 1.26x faster
max: 1000000	34.4 ms	40.9 ms: 1.19x slower
max: 10000000	341 ms	440 ms: 1.29x slower
sum: 1	342 ns	237 ns: 1.44x faster
sum: 10	642 ns	412 ns: 1.56x faster
sum: 100	3.24 us	2.12 us: 1.53x faster
sum: 1000	33.2 us	24.8 us: 1.34x faster
sum: 10000	336 us	270 us: 1.25x faster
sum: 1000000	34.9 ms	40.4 ms: 1.16x slower
sum: 10000000	340 ms	438 ms: 1.29x slower
Geometric mean	(ref)	1.18x faster

I don't know if it's possible, but maybe making a fast path for built-in functions when using generators to speed up that compute at a lower number of elements. This could be interesting to explore since generators require less memory.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[picnixz]

func([ a for a in range(N)])

This should be rather changed into func(range(N)). What's more interesting is when we're doing filtering based on a predicate where the full iterator (or list) cannot be reduced further. However, this kind of optimization should not be done at a function level IMO (and I'm not even sure we can do it easily).

It might be a JIT thing though (cc @Eclips4 @iritkatriel). I think this discussion should however be moved to https://discuss.python.org/c/ideas/6 where the theory can be expanded more in details out there.

Also, see PEP-709 for similar optimizations (namely inlined comprehensions)

[iritkatriel]

It might be that list comprehensions are faster because they are inlined.

But note that if the list is large or the function can terminate before consuming the whole generator, then it might not be more efficient to construct the list.

[picnixz]

I'm going to close this one as not planned. While this is indeed something we want in an ideal world, namely, Python being smart enough to switch from list to generators and vice-versa when possible, I don't think we should keep an issue open. There are other issues when the intent could also be to consume at the same time another iterable:

objs = ...
filtered = [x for x in objs if pred1(x) and pred2(x)]
process(filtered)

If we want objs to be fully consumed before passing to process which may raise, then we cannot use a comprehension. However, I don't know if there is a way to make the interpreter distinguish between this case and the case where we don't care whether objs has still dangling yieldable items. Even if the interpreter knows that process may raise, it might not necessarily know that objs is meant to be consumed entirely.

[Marius-Juston]

This should be rather changed into func(range(N)).

Yeah the example I gave was not great this this would be better:

func( foo(a) for a in range(N) if pred(a))

vs

func( [foo(a) for a in range(N) if pred(a)])

would be more representative

I think this discussion should however be moved to https://discuss.python.org/c/ideas/6 where the theory can be expanded more in details out there.

Sounds good!