>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. For example,
cutting down the syscall keywords from (insert random number...)
40 to 10 will certainly have no notable effect, either in compile-time,
run-time, or, perhaps surprising to many but to the best of
recollection soundly proven, very much in the way of disk image
size either.
Until you know *exactly* what it is that is "slow" and why, I'd
look carefully at all assumptions about issues of speed. Some of
these things, maybe even many, are limited by the speed of the
opcode dispatch sequence.
--tom
