fstengel wrote: ↑Fri Feb 14, 2020 8:36 am
It seems that range(240) is strongly optimized.
Yup. It's specifically the "for i in range():" that is optimized. Calling range on its own behaves like normal. This applies to all emitters (bytecode, native, viper). See compile_for_stmt_optimised_range in compile.c
OutoftheBOTS_ wrote: ↑Fri Feb 14, 2020 6:53 am
Correct if I am wrong but it is the range(240) that takes up all the time because it doesn't create a list that it iterates...If you create a local list then it should run faster but use more memory.
range() (in Python 3) doesn't create a list -- it's a generator. (Back in Python 2, this was the difference between range() and xrange() -- This is why everyone had it drilled into them to use "for x in xrange()" in Python 2).
In general (for a generator function that isn't "range"), the following two snippets are identical:
No list is created in either case so the memory usage is the same.
But, see above, range() is special, so the former snippet is actually much _worse_ when using range().
OutoftheBOTS_ wrote: ↑Fri Feb 14, 2020 6:53 am
through but rather is a global function that has to be called each iteration of the for loop.
The function isn't called for each iteration of the loop, rather each iteration pulls the next value out of the iterator. You're right that calling a global function is expensive, but advancing the iterator isn't so bad. (And again, this doesn't apply for range() ).