On Mon, Nov 28, 2016 at 01:48:23AM +0100, Aristotle Pagaltzis wrote: > How much overhead (size, speed) on scopes would we incur if each frame > had a pointer to the innermost containing loop context? (On each scope > check what type the immediate containing scope is, then either set the > new scope’s containing loop pointer to the containing scope or copy the > containing scope’s loop context pointer.) Could `next`/`last` benefit > from that too? Well there are two approaches: the one you describe, or to add a new interpreter var, PL_last_loop_ctx say, whose old value is stored in the block_loop struct part of the context union and is set and restored when entering or returning from a loop context. That would probably be cheaper. In addition to extra field needed in the loop struct to store or calculate the iteration value (as dicusssed earlier), the extra old_last_loop_ctx field would make the struct block_loop the largest field of the context union, increasing the size of every context union (from about 17 to 18 64-bit words). pp_next() etc are already optimised to check if the top context is a loop context and if so, to not go searching for one; and if it isn't, the extra contexts need to be popped anyway - so PL_last_loop_ctx probably wouldn't make much difference to next/last's performance. -- All wight. I will give you one more chance. This time, I want to hear no Wubens. No Weginalds. No Wudolf the wed-nosed weindeers. -- Life of BrianThread Previous | Thread Next