Re^2: Switch/case (given/when) in Perl5

There's no reason an if/else chain can't be optimized to a jump table where appropriate. In fact, Perl 4 did that optimization, though we never got around to putting it into Perl 5. Anyway, if you think Perl 6's switch structure precludes such an optimization, you are simply wrong. There's no reason to test any expression that you already know the results of, so such a Perl 6 switch statement can be made just as fast as a C-style switch statement if you limit the cases to constants. But Perl can extend the optimization to the case of strings with unique prefixes, and to ordinary if/else cascades as well, while retaining all the benefits of cascading logic in the more dynamic cases.

Comment on Re^2: Switch/case (given/when) in Perl5

Replies are listed 'Best First'.
Re^3: Switch/case (given/when) in Perl5 by Anonymous Monk on Mar 24, 2005 at 09:48 UTC
Do you think someone will get around to adding the optimisation this time? Or will 6.8.x come around and still there will be no optimisations that require looking beyond the current opcode?	[reply]
Re^4: Switch/case (given/when) in Perl5 by TimToady (Parson) on Mar 24, 2005 at 16:43 UTC
Yes, someone will likely add it this time, since the compiler will be written in Perl and not macro-encrusted C. In addition, the compiler is being structured more like an ordinary compiler that separates compilation from execution with the express intention of allowing a better optimization pass in the middle when you aren't running in load-and-go mode. Plus the very fact that there's a switch statement will put people in mind to do it. Your implication that 5.8.x does no optimizations that look beyond the current opcode is incorrect, or at least completely misleading. It would be more correct to say that it limits itself to optimizations on the current subtree and nearby opcodes. But it is correct insofar as it describes the idea that Perl 5 avoids expensive optimizations in the interests of starting up faster. Code movement optimizations tend to be expensive. (The switch optimization is not in fact such an expensive optimization, roughly O(n), I think, since it's scanning for linear consistency, and inserting an extra jump table opcode if it finds such a consistency. There are no stages where it compares everything against everything else.) Anyway, if the switch optimization is so important to you that you are willing to sit there and snipe as AM, maybe you should add it yourself. `:-)`	[reply] [d/l]