At the very least compiling Perl to machine code as is done for C would preclude using string eval. But even if you accepted that as a reasonable limitation, Perl's type system and DWIMery mean that there is a degree of run time overhead that simply can't be removed. Altering Perl to remove that overhead would alter the language - it wouldn't be Perl any more and most of what would go would be exactly those elements that make it fast to develop in.
In fact for the core operations that Perl is tuned for (string and array manipulation) execution speed is generally quite acceptable. The trick is to code so that most of the work is done inside Perl constructs such as regular expressions, string functions and array manipulation functions.
Compilers for languages such as C++ use the information that strong typing provides to optimise code - often spending much more time in the optimisation phases than the basic compilation phases to achieve good results. Strong typing provides strong constraints on how code is written which allows optimisers to work well, but can really slow down code development. Writing the code becomes much more fussy!
At the end of the day you choose the language that best fits your skill set and is most applicable to the task at hand.
In reply to Re: compiling perl scripts aka why is perl not as fast as C
by GrandFather
in thread compiling perl scripts aka why is perl not as fast as C
by punkish
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |