Did you test the performance of the perl programs (vs. equivalent C code) on your machine? Chances are relatively decent that your machine is better than my clunky 133 MHz Pentium.
Fact correction: Perl is a compiled language, actually (well, as compiled as Java, anyhow). The perl program works by taking in your source file, and compiling it in several stages.
Stage 1: the compile phase. In this phase, Perl converts your program into a data structure called a "parse tree". If the compiler sees a BEGIN block or any "use" or "no" declarations, it quickly hands those off for evaluation by the interpreter.
Stage 2: Code generation (optional). If you're running one of the compiler backend modules (such as B::Bytecode, B::C, or B::CC), the compiler then outputs Perl bytecodes (much like a Java .class file) or a standalone chunk of (very odd-looking) C code. These code-generators are all highly experimental at the present.
Stage 3: Parse-tree reconstruction. If you did stage 2, stage 3 remakes the parse tree out of the Perl bytecodes or C opcodes. This speeds up execution, because running the bytecodes as-is owuld be a performance hit.
Stage 4: The execution phase. The interpreter takes the parse tree and executes it.
This is Perl compilation in a nutshell... read Chapter 18 of the 3rd edition of Programming Perl for a more in-depth analysis.
For many tasks (especially simple ones such as these) Perl will be slower than C, because C is basically a more-portable form of assembly language, and assembly language (once actually assembled) works with raw hardware, and is hence as about fast as you can get.
Another difference between Perl and a native C app that may affect performance is the fact that Perl has its own stack (actually, it has several stacks) as opposed to a C program, which is likely to just use the system stack. | [reply] [Watch: Dir/Any] |
I add my voice to this: the should be a way to inline
functions and method calls.
Granted you can use the pre-processor (perl -P)
to inline functions but this does not work for method calls.
This is really bad when designing OO Perl, where I find
myself using straight hash access ($o->{field}) instead
of accessors ($o->field) for some often-called methods
(or writing painfull and risky kludges),
which makes maintenance much harder
I am actually very surprised this is not even a Perl 6
RFC, I would
think that this is a simple (I would think it is quite easy to
implement) way to enhance speed or maintainability of OO Perl programs.
| [reply] [Watch: Dir/Any] |
Well, since it'd probably be just an attribute on a subroutine, and we already have those, there's nothing really to RFC. {grin}
Ideally, the Perl compiler would just recognize when a subroutine qualifies as
an open-coded version, and "do the right thing". I'd prefer that. Just like how
certain subroutines are recognized as "constant" now, and pre-evaluated.
-- Randal L. Schwartz, Perl hacker
| [reply] [Watch: Dir/Any] |