At 03:41 PM 3/28/2001 -0800, Hong Zhang wrote:
>Are we over-optimizing? The Perl is just an interpreter language.
Perl's not just an interpreter language, and hasn't been for a while.
(Granted the bytecode compiler's not fully functional, but it does work in
some cases)
>Who really needs this kind of optimization for Perl?
I do. Lots of people with web apps do. Pretty much anyone with a large or
long-running perl program does.
>Even C does
>not provide this feature.
C doesn't have the sort of sort function that makes this possible in the
first place, nor does it have the sort of data that makes it a reasonable
thing to do. Perl does, so some optimization is reasonable. Whether it's a
good first spot to optimize is an open question, but it will be a big win
for quite a few people.
>Though Pascal/Ada have distinctions
>like function/procedure, it does not make them any faster than C.
Depends on how the function's written in C. A function that has no
meaningful return yet still returns one which gets inevitably thrown away
will cost more than one that never returns anything, and there is a
tendency to return *something* since you can.
>Just given its ugly name, I hate to see it in the core language.
What, the ST? Why on earth would you think that we'd make much of a big
deal over it in the docs? I'd just soon not mention it and just put it in
as an optimization and have it be a pleasant performance win.
>If people really want to optimize Perl, they can write a native
>compiler for Perl with advanced garbage collector, just like
>Scheme or Strongtalk compiler?
What, as opposed to the interpreter with advanced garbage collector? :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
