I'm not sure I agree. Actually, I'm pretty sure I don't.

Modern JVMs are faster than the 1.1 or 1.2 JVMs, yes. But CPU speed has also more than doubled since then. More like 5 or 6 times speed boost. And memory is dirt cheap - I started with Java 1.1 on 168MB RAM. I'm now running perl on a machine with 4GB RAM. I'd wager that Moore's law has taken care of more of Java's speed problems than Java has.

Java still has a significant object overhead, even compared to perl's far-from-zero overhead. This puts an upper barrier on how fast the JVM can go. And you just can't do that much interesting in Java without objects.

What really gets me is the Java startup cost. Perl can compile, optimise, and execute some activities faster than Java can load, initialise itself, and execute a pre-compiled .class file. And then Perl has mod_perl to take care of that problem. Oh, no, sorry - that eliminates what little startup cost there is for perl, at least for a subset of the problem. Yes, you can do the same for Java. Memory usage shoots right up, though...

My last point is that the amount of abstraction you need to get a job done in perl is quite different from Java. Yes, in perl, you can go whole hog. In Java, you often don't have a choice but to go all the way.

I'm still way more productive in perl than my Java-writing peer. And he knows it. In the end, it doesn't matter to him because he still is getting paid, which is really the bottom line to him.

Perl's development speed is faster, but from what I've seen of Java, trying to code 00 Perl in the style most Perl programmers use seems to be quite a bit slower. Compare the speed of Lucene versus Plucene or XProlog versus AI::Prolog. Perl loses hands down. These started as straightforward ports which is part of the problem, but their coding styles don't seem significantly different from what I see many Perl programmers use.

On the other hand, I hear people claim that when Perl is coded in a more idiomatic style, it competes quite handily, but I'd like to see benchmarks against real-world applications rather than samples.

Cheers,
Ovid

New address of my CGI Course.

FWIW, you could always try the shootout.

Yes, Plucene may be much slower than Lucene. But that's because the concept was IIRC taken one-to-one. Java has it's language pro's and Perl has it's language pro's. But they're not the same.

---

Ordinary morality is for ordinary people. -- Aleister Crowley

Comparing Java servlets with mod_perl handlers gives very close results. I don't think the slowness people often experience on Java sites has to do with the actual language as much as the choices made when developing in it.

Comparing Java servlets with mod_perl handlers gives very close results. I don't think the slowness people often experience on Java sites has to do with the actual language as much as the choices made when developing in it.

That's been my experience. It's not Java per se that causes slow down and bloat, but the huge frameworks that are brought in for the simplest task.

I'd tend to agree with this point, but will concede that it depends on the quality of developers on both sides of the fence; it's possible to write crappy perl that's not maintainable, it's also possible to write GREAT java that is as flexable and maintainable. I believe the latter will take a lot longer, and involve more highly skilled people to write than it will a good (GREAT?) perl version.

-Scott

it depends on the quality of developers on both sides of the fence

Paul Graham had a point about Java programmers compared with (in this case) Python. :-)

I do know great people that use Java, but still... I think he has a point.

(I'm no Python fan, so Graham probably doesn't care about my opinion. :-) I guess I could get used to the white space craziness, but it bores me. A nice lisp version might tempt me if I can choose language.)

Let's not spread FUD here: Java is not slow.

I think it's more a misunderstanding than it is FUD. When technical people hear "fast" or "slow", we tend to think in terms of how efficiently a technology will perform. But when business people use those words, they tend to mean "how soon can I have it?"

Well-coded Java might outperform well-coded Perl in some cases, but Perl (or Python or Ruby) will often get you there a lot quicker, without spending time wrestling with language that wants to put you into a straightjacket for your own good. Sooner and slower usually beats later but faster.

In this case, I'm pretty sure the OP was referring to execution speed, not development speed.

True, I was. I may well have used Java apps that were fast, but I didn't notice. I do notice waiting 15-45 seconds for a page to render in my browser. I'm not trying to spead FUD, and you're point is well made. I think that the issue for the company that is switching to Perl is memory footprint - which is only tangentially related to speed.

What FUD do you mean? Whenever I happen to stumble on a page with a Java applet while browsing the Net my computer basically just stops responding for several seconds. Whenever I start the stupid IP Phone application we have here it stops responding for 15-30 seconds. Not just that it takes 15 seconds for the app to appear, nothing else gets to do anything until Java loads and initializes and does other things I don't want to know about. Yep, FUD. Pull the other one.

We are not talking about Java applets here. This is about sites with a backend coded in Java and no Java on the frontend. That is the primary market for Java and has been for years. Applets were a short-lived fad.

Damn, I wish you could convince Rational of that. ClearQuestWeb uses Java applets coming out the wazoo, and I've seen their new version - which has become one big Java applet.

I'm not actually trying to disagree with you here: I really do honestly wish someone would give Rational a cluestick! (Although the Java applet version is more likely to work on my Linux/Firefox system than the current ASP-based application which only really likes IE6.)