It's also possible that the Perl code was awful, written by people who have never heard of CPAN or profiling, but the biggest hit is typically CGI.

Remember, Amazon.com runs large amonts of its site on Perl with FastCGI, and so does Ticketmaster.com (on mod_perl). It's well-established that Perl has good performance.

I've seen just the opposite: we used to host a rather well visited web-site for an airport with close to real-time flight information (1 minute delay). This ran on a Solair box with Slowaris 5.6 (if I remember correctly). The machine had a whole 32M of RAM (yes, Megs, not Gigs). And this was co-hosted with other sites on the same machine. It ran Apache with PHP generated from Perl scripts initially. Later it became mod_perl with a templating system I had developed.

Then a corporate decision was made by the client that this should be converted by a "real" IT company to Java. When they said their solution was ready, they switched over. Only to switch back to the old situation within 4 hours because the new system collapsed under load. Six months later, they finally had their act together and the final switch was made. With a lot more hardware!

To this day, I find that site less reponsive than our version of the site had been. I guess you could call that progress.

Morale: not sure. Anyway, I know why I want to work with Perl. That's important enough for me. And for my clients who believe in me.

Liz

What would you want these guys to do anyway? Invest a lot of resources implementing the site for a third time, just because you got a hunch a Perl solution could be faster? Unless you create one yourself and show it to them, there's no way they'll switch back to Perl. It wouldn't make any sense for them.

Abigail

I was looking for something along the lines of either:

"Obviously good Java is faster than bad Perl, but xxx-case-study shows that implementing Perl-yyy on zzz outperforms Java. They must therefore have been running bad Perl."

OR

"I'm afraid it's true, at coding-quality equal, Java will always beat Perl in web applications."

whichever is true.

...I'm not sure that either of these is valid. Each case will be different, and there's always the possibility that a different approach with either language (Java or Perl) will yield performance improvements that surpass the other.

To me, the difference between them is that of the answer to the question, "Which is better, Ford or Chevy?" If I have both, then I don't really care which is better (if there is an answer to the question at all). I can use the one that fits my needs in any given situation. The distinction between Perl and Java lies in the context. And I boil it down to this. If you want something built really quickly, and if you have one programmer working on it, then you probably want Perl. If you want something that will be built by a team of developers, and if the skill levels among them is disparate, you want the protection of a strongly typed, necessarily object-oriented language like Java.

A healthy IT shop would use both of them abundantly. But in most cases, the "surface dwellers" (Defined by me as meaning "those who don't actually code or test, but learn everything they know about IT from the industry rags and the in-flight magazines...) develop a jaundiced view of Perl from exposure to shoddy consultants, FUD-bearing industry sales drones, and jury-rigged benchmarks or anecdotal case studies.

Want to do the best thing for your career? Then learn both languages well, and be familiar with the performance implications of not only the languages you choose to implement, but of the services and protocols that are being used in the system that is being measured.

My first guess about the situation you describe is that the overhead that caused the Perl solution to be slow was imposed not by Perl, but by the communication protocol in use. You can usually count on the fact that JSP resources will execute and scale better than CGI. (Although this is not a universal truth.) So for instance, I could devise a test in which it could be shown that Java is dog-slow compared to Perl.

If you write a Java class file that contains a main() and serves the same role as a standard CGI program, it will absolutely poke along compared to the Perl counterpart. Java suffers from poor startup time latency due to the class-loader validation step that checks for bad code, and sometimes for security violations.

So most successful system implementations in Java will account for this by starting and loading classes early (ideally at server startup time in the .rc scripts) and then leaving them resident for when the demand occurs. I'll lay odds that this is the difference between the two approaches rather than the change of the programming language.

Or here's a pithier way to put it:

PHB: That's why we use Java instead of Perl.

You: No. You use Java instead of Perl because you know Java and you don't know Perl.

...All the world looks like -well- all the world, when your hammer is Perl.
---v

Is there anything to say to these guys to defend Perl?

"Hire better developers."

Is there anything to say to these guys to defend Perl?

One can either say Java is faster, or Perl is faster, but you have to give sound reasoning. If the conclusion is just based on one or two projects, then it is absolutely immature and illogical.

Most of the time, performance is not really determined by the language, although this might be true for single modules, but not the entire system. Language is generally speaking not responsible for the performance of the system (at least not a main component of the cost). What really should be responsible in most of the case, is the architecture of the application.

You did an application with an old architecture in Perl, and now do it with Java but a new architecture, which one is faster? Obviously it should be the second one, unless the skill of your designers is way below average.

So those comments you mentioned in your original post are meaningless to me, to be frank. So don’t bother at all. There is no point to join the battle, as they are comparing apples with oranges.

If you're looking to convert this company back to Perl, don't bother. They've already got a working solution, and there's no point in undoing all the hard work again just so your favorite language can be used instead.

If you're looking for defenses against PHB's who look at this and try to force their own departments to switch, consider what perrin said. This company almost certainly wasn't using mod_perl or FastCGI or some other embeded interpreter, whereas they almost certainly were doing the equivilent for Java.

For a fair comparison, one only needs to write a "Hello, World!" in both languages, compile the Java program, and run them both. The Perl program will be done long before the JVM even finishes loading.

That test is mostly irrelevent, since nobody actually runs a Java-based web app like that (nobody sane, anyway). Similar to mod_perl, Java servlets have their JVM built into the web server, so JVM startup time can be ignored. Naturally, the same goes for Perl code running on a web server with mod_perl.

I strongly suspect that the company in question is making an unfair comparison. Ask them to convert all their servlets to Java CGIs and see how fast they run :)

It is interesting to compare the predictions made about Sun there with Sun's recent financial reports...

Hardburn got it, and perrin and others had great ideas. Thanks.

Yes, my motiviation in asking this question is that if it becomes "common knowledge" among the IT managers of the largest companies that Java is faster than Perl, then teh days of Perl programmers are numbered. I don't want that because I like programming in Perl. This is almost a matter of marketing, or of politics: If I want to work in Perl, I can't let insane ideas like that be perpetuated.

Perkl hackers have to remember that a lot of the world - I'd dare say most of it - is, as someone put it, terribly ignorant of Perl. Up to us to change that or die out as larger communities, and programs with big-buck backing, try to climb to the top by pushing others down.

Yes, my motiviation in asking this question is that if it becomes "common knowledge" among the IT managers of the largest companies that Java is faster than Perl, then the days of Perl programmers are numbered.

It could be argued that if large, bloated companies working on large, bloated projects use a large, bloated language in an unfailingly poor way, then they will be utterly destroyed in business by nimble, agile software developers working in small, well-knit units. (Or have their product cloned on Sourceforge by a few hundred slackers.)




-----------------------
You are what you think.

Why would you feel the need to defend Perl in this case? What will it buy you? Are you a software reseller who makes money from selling boxed sets of Perl CDs?<g>

Sure, you and your colleague can possibly banter about one versus the other. However, unless you have a compelling interest in it, what's the use? Between you two, this could easily turn into another "emacs vs. vi" kinda thing.

It's really more a matter of personal interest in the long view.

If Java developers are going to be regularly showing up Perl developers, and if the IT management of the largest corps are of the opinion Perl is slower than Java and, even worse, if that turns out to be true or undefendable, then what is the future of Perl and Perl programmers?

The answer may give existing Perl programmers - like myself - either motiviation to commit further to Perl as a career path, or consider keeping their options open.

The answer may give existing Perl programmers - like myself - either motiviation to commit further to Perl as a career path, or consider keeping their options open.

You speak as though the two options are mutually exclusive. If you are already a professional perl programmer, then I can't imagine that you'd have to do a lot to keep that maintained. However, if you see the direction of your company (or companies in your line of business) going towards Java (or any other technology for that matter), you'd be foolish not to try. In biology, they have a word for those that don't evolve: extinct.

thor

pg has suggested architecture issues, while perrin has suggested investigating cgi technology and code profiling.

As I see it, the ball is back in punchcard_don's court to get this info for further contemplation.

I once got bitten by the piggish perl module "Math::BigInt". By replacing that with custom code, my app ran 30 times faster. So, I'm suggesting that something simple like that could be responsible for the apparent poor performance by perl. This can be identified by code profiling.

• Write your system.
• If performance is unsatisfactory:
  • Profile to determine bottlenecks and re-code those sections.
  • Consider alternate algorithms.
  • Examine configuration and framework ( eg: Apache ).

--
TTTATCGGTCGTTATATAGATGTTTGCA

I can tell you an exactly contrary story. With a one time employer I replaced approximately 13,000 lines of Java - and all of it is now Perl. He had a suite of automated testing tools for the equipment he manufactures, a variety of tools had been implemented with Java after a very keen young rooky graduate had sold them on the idea.

I was a researcher with his company and kept as far away as I could from production. One day I was sitting quietly at my desk (huge open office with senior staff at one end of the room looking out huge glass windowsm very nice) when I heard my friends door slam and much shouting going on inside. Poor young Java developer (had been there two years by this time) was having problems implementing some apps for trouble shooting a product in pre-production. He had promised it for two weeks before and hadn't yet delivered.

So after he was sent back to his desk to get to work on something else I got called in (not unusual as we had known each other and worked together on and off for nearly 25 years). We had coffee, talked about it for a bit and then I was asked - "Well, when you have to exercise your hardware designs what do you use? Don't you use the production suite?" "Oh no" was my reply, "I do my own in Perl". All this testing is pure stimulus and response stuff. The problem with the Java guy was that he was basically trying to do everything from the ground up in Java. So to test this product he had to write a full suite of SSH client, FTP client, FTP server, and all the proprietary stuff.

I turned to a spare machine in his office and logged on as me, sat with the product specs - I had been lead designer for the thing anyway, pulled up my Perl collection of code snippets, hooked up the test bed to the ethernet and away we went. Between my snippets and ethereal (wonderful thing!) we had written code to exercise the widget, found the problem and got the embedded C cutter into the room and fixed the problem before night-fall.

The following day I hired a Perl coder I knew and he turned my snippets into a suite to replace the Java. When we finsihed about three wekks later and put it in productions test bay they reported that the test sequences that took 4 hours on one product were suddenly taking only 23 minutes. On another, the sequence went from 13 hours to 1hr 17minutes. So two years of Java at $25/hr was replaced with Perl in three weeks at $70/hr. Production throughput went up, we used browsers for the GUI, and with the addition of MRTG and a few other standard things we built a much easier to use environment.

Oh what happened to young Java coder? He is still there! (I'm not, I moved continent in the meantime.) Every time we speak he makes a joke about Java, but he also admitted one day that Java had been so mu7ch the falvour of the month when he did his CS degree that he was blind to anything else. Perl was considered particularly un-cool. But now having learned Perl he is happy that un-cool things like Perl have kept him in a job with a nice salary increase and the ocassional "well done". Especially as he was within 24 hours of being fired.

jdtoronto

A 6x performance gain when going from Perl to Java sounds awfully suspicious. There has to be more to the story.

Is there any chance that your colleague's site was a vanilla CGI application rather than a mod_perl or FastCGI app? (I'm assuming this is a web-based app) If so, those numbers might quite reasonable, but the joke's still on them.

Were there optimizations that occurred to the database(s) in the meantime? Like new/improved indexes or stored procedures? Talented DBA work can offer stunning performance increases.

I'll be the first to admit (possibly wrongly) that Java has a performance edge over Perl, when both are given equal luvin' and skill, but NOT 6x, probably not even quite 2x. And I say this a someone who is experienced w/both languages. Perl is the apple of my eye because it takes ALOT less effort to write and maintain.

I would be surprised to learn that Java has any inherent performance edge over Perl; my assumption was that Perl is, in some undefinable way, "closer" to C than Java, and that C is the performance standard by which most non-assembly languages are compared...