views:

166

answers:

5

I recently had a friend tell me

"see perl was never designed to be fast"

  • Is that true?

The relevant piece of information I can find is this from Wikipedia:

The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal).

But it doesn't directly talk about speed. I think that with all the text processing that it needs to do, speed of execution really matters for a language like Perl. And with all the weird syntax, elegance was never an objective, I agree.

  • Was high speed of execution one of the design objectives of Perl?
+1  A: 

It became a design objective as of Perl 5.0. But keep in mind it is still interpreted, so it is fast for an interpreted language.

Brent Arias
It's not any more interpreted than, say, Java or C#.
reinierpost
@reinierpost. C# and Java have JIT - Perl doesn't. Interpreted nature of Perl shows up fast if one tries to do lots of arithmetic. Though that in large is offset by Perl cleverly mapping whatever programmer writes onto the plethora of efficient internal functions and algorithms. Java/C# with their intermediate presentation (bytecode/CLI) lose quite a lot of the bigger picture in the process...
Dummy00001
@Dummy00001, JIT isn't magic fairy dust that makes Java or .NET faster. Last I looked at how the JVM was doing JIT it wouldn't even bother to JIT most byte code, it only did so for code it knew it would get a significant speed boost from to offset the cost of using JIT. While Perl admittedly can't do this at runtime it does achieve much of the same goal by providing both pure Perl and XS versions of key algorithms and tools on CPAN.
Ven'Tatsu
@Ven'Tatsu: you haven't read till the end of my comment? ;)
Dummy00001
+3  A: 

I would have said that a language that designed for optimal run time performance would not have constructs that allow compiling while running. So no, perhaps.

Preet Sangha
+7  A: 

Perl has always aimed toward practicality, not anything (even close to) some sort of ivory tower purity, where a few goals are given absolute priority, and others are ignored (completely or nearly so).

As such, I think it's reasonable to say that maintaining a reasonable speed of execution has always been seen as important for Perl, but there are other factors (especially things like flexibility and ease of use) that are generally more important, so if a choice has to be made between one of them and speed of execution, the other factor will generally win unless the effect on execution speed is really serious.

Jerry Coffin
+9  A: 

There is one important aspect to be considered : algorithms. Perl secret weapons are the algorithms backing certain language features and the CPAN library.

Good algorithms trump raw execution speed for non trivial problems. It typically takes more effort to select and implement algorithms in C-like languages than in Perl. This means that for half a day coding some little tool the perl version often outperforms a C version because it was easier to make good datastructures with hashes and by using the features provided in the language and libraries.

Peter Tillemans
+8  A: 

Once a Perl script starts running (i.e. after loading and compiling everything), it can be very speedy. It's that yucky compile-every-time that's a bit nasty.

However, I find that people don't really have to worry about how fast Perl can be. They waste all of their time by implementing stupid designs that do a lot more work than they need to do, misunderstanding key technologies, or just being boneheaded. It's not uncommon for me to help someone make their stuff go orders of magnitude faster by just tuning in the right places. That's not particular to Perl though. People have that problem with every language.

brian d foy