On Wed, Nov 07, 2001 at 05:15:14PM -0500, Dan Sugalski wrote: *) The program is fully parsed *) There are no string eval, do, or requires *) There are no symbolic references on the LHS of any assignment *) There is no use of MY within the block or in any subs called by
> Since you don't know, you can't assume it'll do something safe. And while > it's potentially possible you just de-optimize code, it's fairly > non-trivial to recompile a block you're already in the middle of, > especially if you're in the middle of another block (like a sub) and need > to rebuild a parent block such that you can still return to the spot you > left from. (Try it when the code that triggers the recompile is caused by > accessing a tied variable so that you're rebuilding an expression you might > be in the middle of) Is there enough win in doing that optimisation on an innermost block that doesn't call anything? Maybe on a deferred basis - track if the block is suitable for optimising on the first run through, and if it loops at the end then do the serious optimisation. That way, something like while (<>) { print if /foo/; } would run through for the first line and if it found no violations of your 4 bullet points by the end of the block, it would then perform the vtable bypass operation on that block only. Also, after reading this thread, I suspect that interpreter generated things like the (lazy?) list due to .. in foreach (1..10000) { } will find fast integer ops useful. Nicholas Clark