At 04:37 AM 8/4/00 -0600, Tom Christiansen wrote:
> >Point taken. But part of the goal was moving a lot of stuff out of CORE
> >and making Perl faster. New features are great, but we should figure out
> >whether or not they're truly CORE-worthy. Sticking it in a pragma like
> >strict helps to solve this issue, but as always TMTOWTDI.
>
>I find the notion that Perl will become appreciably faster simply
>by having fewer default features to be unlikely.
If we go the double-indirect opcode function route, cutting down on the
number of opcodes may well help, as will careful grouping of the opcode
functions so opcodes that execute in sequence have their function pointers
close-by. This'll reduce cache misses, which is a good thing.
It also reduces the number of opcodes the optimizer (and the people writing
the optimizer) need to deal with, which isn't a bad thing either. (Though,
granted, I really doubt anyone'll spend any significant amount of mental
effort on the localtime op)
Finally, it may make things slightly easier for folks writing
JIT/compiler/translators for perl bytecode. If we yank the 'odd' ops out
into separate functions, and the doodad writers provide an interface to the
non-op functions, it means they don't have to worry about writing code to
do localtime however we do it, they can just call our function.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
