Specialize FOR_ITER opcode

[GoogleCodeExporter]

Currently we make an indirect call to iter->ob_type->tp_iternext, we should 
specialize this for lists and tuples (and maybe dicts and sets, those would 
need extensive benchmarking).

Eventually we'll want to make it so iterating over a known type for loop 
doesn't even allocate an iterator, since it never under any circumstances 
escapes the frame, for now a good start would be just inlining the body of 
{list, tuple}iter_next

Original issue reported on code.google.com by alex.gay...@gmail.com on 22 Feb 2010 at 6:20

[GoogleCodeExporter]

This is definitely worth doing.

A follow-up would be to eliminate the GET_ITER code as well and simply guard on 
the type of the incoming object.

Do note: if we eliminate the list/tuple iterator object in the LLVM-generated 
code, we 
will need to materialize one of these objects on top of the stack if we bail or 
raise an 
exception. This will require chained bail/exception blocks via a stack 
mechanism; 
GetBailBlock() and GetExceptionBlock() should be extended to handle the new 
stack 
semantics.

I've worked on this before and got caught out by this point (then got busy with 
other 
stuff).

Original comment by collinw on 22 Feb 2010 at 4:41

• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It occurs to me that dict/set iterators are slightly more complex, in that they 
can 
raise an exception (if the structure is mutated mid-iteration).

Original comment by alex.gay...@gmail.com on 22 Feb 2010 at 4:57