That doesn't sound to me like a language issue. It sounds like an algorithm issue or a bottleneck somewhere. I would start asking questions about rendering time in the browser, database connections, and the like.

Unless, of course, there was something inherent in what it did that made 5 seconds seem like a reasonable amount of work to do...?

Understand, this particular page was doing a huge amount of processing (a lot of nested loops) before producing results. The actual page generation was done after the processing, and was essentially a single print statement, e.g., print join( "\n", header, start_html, ..., end_html ), so there were no speed issues in that regard (trust me -- there might have been, but in this case there weren't).

My point was that, after accounting for the process startup time, compile time, etc. of an otherwise standard CGI Perl program, the net run time was probably about three seconds (give or take a half second or so). In contrast, the Java Servlet implementing the same algorithm took roughly five seconds (also, give or take about a half second).

In my opinion, Perl beats (non-JIT inlined) Java in raw performance.

Well it is a known factoid: Perl compiles to high-level bytecode, ie many builtins compile to a single opcode, whereas Java bytecode mimics a real CPU, so you are essentialy pitting a P-code interpreter against a hardware emulator. The P-code is almost bound to win.

The well known strategy of optimizing Perl programs by tuning them to spend a maximum amount of time running builtins (see Schwartzian Transform f.ex) highlights this issue clearly. Java optimization is very different and much closer resembles traditional optimization.