Hacker News Reader

Comment by jerf | Hacker News Reader

Perl... performance?

http://benchmarksgame.alioth.debian.org/u32/which-programs-a...

Perl is solidly in the lowest tier of serious language performance, and that result is quite robust no matter how you query that site, and correlates to my personal experiences as well.

Perl isn't alone... it's joined by many of its 1990s-style dynamic scripting language buddies with very similar performance. And of course many fine programs are written in them nevertheless, so I don't mean this as a criticism... in fact if you read this as a "criticism" that needs to be "rebutted" in some sense you're entirely missing my point. I really shouldn't have to "qualify" this to fend off the obvious replies, but I've been around enough to know I do. But, it's true that a serious professional should be aware that Perl is in the slowest executing set of languages, and it is very possible for the difference to be significant for you in many commonly-occurring tasks.

View on HN

Having developed in Perl for many years, on a project that required fairly high performance, I learned that the key to getting good performance out of Perl code is to use it idiomatically.

Perl has a lot of built-in functions, keywords, and operators. It's also a bytecode-compiled language (yeah, Perl is compiled when you run it, the compiler is just so fast you don't notice it.) But a lot of those built-ins don't compile to the bytecode equivalent of machine code for a VM like you might expect; they compile to a single instruction that's got an optimized implementation written in C. When you write idiomatic code, you tend to use built-ins in a way that allows those optimized instructions to be used, which gives you near-C level performance.

For example, if you want to loop over every member of a list, perform an operation on each member, and produce a new list based on the results of those operations, you could use a 'for' loop for that. But if you do than the Perl compiler needs to produce bytecode that mirrors the generic for loop and the full code in the body of the loop, pretty much as you wrote it. The compiler can't make any assumptions about the intended behavior. If you instead use the 'map' keyword, the compiler knows that you're transforming one list into another by running a bit of code on each member of the list, and it'll produce much more optimized code to do that.

It's kind of ironic. You can write 'C' style code in Perl but you won't get C-like performance that way, you'll get Perl-like performance. But if you write 'Perl' style code instead, you'll get C-like performance.

Perl is not bytecode based. It compiles to a data structure, essentially an AST. I've never seen anything close to C-like performance from Perl, not in anything computational.

I was being kind of loose in my technical description. Perl is similar to true bytecode-based languages in that it gets compiled into a lower-level representation that is not native machine code, and then that representation gets executed by a program that behaves like a cpu whose native machine code is the symbols used in the representation.

But you're right, Perl's implementation of this strategy isn't like classic Pascal or modern Java's implementations. But that doesn't alter my point; writing idiomatic Perl gives you a smaller AST with symbols that execute optimized code.

You're also right about Perl not having C-like performance for anything computational, because there you're dealing with Perl's data types, which are powerful and flexible but not efficient, as the article describes. My point was more about looping, set operations, string manipulation, conditional statements, and data structures. Perl has both efficient and inefficent ways to handle all of those, and it pays to learn to use the efficient expressions.

As my boss, who has built our nearly 20-year old company in Perl, says: "If you wanted fast, why did you choose Perl?" I think that the comment you were responding to implicitly meant "Perl performance vs other dynamic languages," not vs something like C. I didn't downvote you, but I assume that's probably why you've been downvoted.

I see no evidence that Perl is particularly faster than the other dynamic languages, either. Ruby was often slower for a good long time, but seems to have caught up to rough parity. CPython generally has a slight (but in practice irrelevant) advantage over it.

You know, the picture becomes to come into focus to me. I suspect due to the prevalence of the saying "Languages don't have performance, only implementations do" and people constantly slagging on benchmarks without thought, simply reflexively, and probably helped by a healthy dose of both fanboyism and instinctive revulsion to fanboyism, programmers are apparently nearly completely incapable of having a reasonable discussion about which languages are faster than other, at what tasks, under what circumstances.

Well, that's a pity, because there is such a discussion to be had, and a lot of people are getting hurt because of their inability to get good information on this topic, and consequently making perfectly-avoidable bad decisions. Absolute statements are hard to come by, sure, but there are engineeringly-useful guidelines that you can discover if you examine the problem space.

There is a ton of dogma there, one of the reasons why I studiously avoid any 'which language is better' arguments if I can. The only thing you tend to learn is how the camps are laid out, without any objective data about applicability or strengths and weaknesses changing hands.

I try to imagine a discussion between carpenters about chisels, saws or hammers and each having a favourite brand that they'd defend to the death in order to avoid an objective discussion about what the good and bad properties of each tool are.

This is exactly why I wonder why some companies write things such as 'must be passionated about Java' in their job postings.

After all, programming languages are just tools. What really matters is the applications you create with them, and that people will find your application useful and use it with pleasure.

I tend to be worried when I see somebody describe themselves as "passionate" about a programming language. Good programmers, I have found, are passionate about programming, and all too often those who are passionate about a given tool are really much closer to zealots.

I don't know about carpenters, but my cousin who is a mechanic rails on and on about how this particular tool is better than the other, and only idiots would risk their lives lifting a car with that automotive lift.

Where there is choice people will complain about the choices of others.

If someone has no preferences about tools, I doubt he has any experience at all.

There's preferences and there are religions.

How would you draw the line in the case, of say, text editors?

As soon as you start to try to win people over to 'your camp' it's a religion.

Up to that point it is just your preference.

What do you consider a "serious language"? In its class of languages Perl is one of the fastest. Anyway, this is about speeding up Perl and not "Why use Perl instead of <compiled language of choice>".

"What do you consider a "serious language"?"

Ironically, you're being prickly in exactly the wrong direction. Perl is totally a serious language. I do most of my work in it, in fact. I qualify it with "serious language" because when I say it's one of the slowest serious languages, it's no fair to counter that by pointing out somebody's hobby implementation of Lispcheme that's a hundred time slower.

"In its class of languages Perl is one of the fastest."

Well... I suppose... since essentially all original C-interpreter implementations of the 1990s-style dynamic scripting languages have performance within about 20% of each other, that's not false... but the marketing-style implication that Perl is the fastest certainly is false. (Also LuaJIT is way faster, but does "compromise" relative to some Perl features to get there.) Drop the "C-interpreter" clause and Perl's in real trouble... Javascript isn't the C-speed language it sometimes gets presented as but JIT'ed JS really will handily beat Perl, and PyPy is... weirdly complicated from a performance perspective.

The point is still that talking about Perl as a perfomant language on almost any measure is... very weird. It's not. It's possible to name several serious languages which are as slow, but not one that clearly slower.

It feels rare to find someone who can be honest about the shortcomings of their day-job programming language. Kudos to you!

Seriously. I've run into static from fanboys at pretty much every job because of it. People getting prickly because of criticisms about Java, because...well, they write Java. (I rarely say they know Java, but, different problem.) Seeing some frank discussion, as is going on in this thread, is really nice.

Perl's (C-based) regular expressions make it faster than many compiled languages for lots of real world tasks.

Indeed, a "slow" scripting language gluing together fast C functions is a very productive strategy. Tcl/Tk is another example. Or NumPy.

PHP as well which in many areas is just glue over C in design.

Context is everything right? perl is consistently fast enough for the tasks it is well suited for. And within its space it is quite performant.

Last year, my entry for level0 of stripe3 was a tiny perl script with no tricks (http://pastebin.com/XLZmmPX7).

Using perl, you can not win speed benchmarks, but a C program significantly faster than the "normal" perl program, needs much much more development time.

I have already encountered a C project that was rewritten in perl because it was a maintenance nightmare. The client was very surprised by the performance increase.

I do not know what are your "commonly-occuring" tasks, but in my experience, perl performance was never the bottleneck.

You shouldn't be comparing Perl and the rest with C, but Perl with other dynamic languages that have modern implementations like Lua, Lisp, or JavaScript.

While general "computational" tasks are bound to be slower in Perl, it holds its own in text processing. I've had better performance from Perl than awk, grep, and even sed in some of my own tests (not to mention that the programs are orders of magnitude easier to write).

It even seems from those benchmarks you posted Perl did quite well in the reverse complement and regex DNA tests, as I would have expected.

> Perl... performance?

You have to remember this idea comes from the late 90s when Java was slow as a dog, and Perl solidly cleaned the floor with other scripting languages like Python, Tcl, (was Ruby even known then?).

Perl even outpaced C++ for I/O related stuff due to the way Perl buffered input (or maybe the way C++ streams were so badly implemented). Of course a clean slate implement in C++ that avoided...well C++...and used mostly C style code would have cleaned the floor with Perl...but that was the state of C++ in the 90s.

Yeah...Perl had its heyday.

Reply on news.ycombinator.com