Take a look at Perl's lousy showing in the recursive Benchmark for what I mean about subroutine/method performance.

Well, lousy verbose coding is a big issue here, too. Removing unnecessary allocation of variables and explicit return calls where possible, and replacing the named subs with coderefs

# The Computer Language Shootout
# http://shootout.alioth.debian.org/
# recursive test, by Andreas Koenig, Sep 24 2006

### Uses temp variables to help perl free memory earlier

use strict;
my($Ack,$Fib,$Tak);
$Ack = sub
{
        my ($x, $y) = @_;

        return $y + 1         if $x == 0;
        return $Ack->($x - 1, 1) if $y == 0;

        $Ack->($x - 1, $Ack->($x, $y - 1));
};

$Fib = sub
{
        my ($n) = @_;

        return 1 if $n < 2;

        $Fib->($n - 2) + $Fib->($n - 1);
};

$Tak = sub
{
        my ($x, $y, $z) = @_;
 
        if ($y < $x) {
          my $z1 = $Tak->($x - 1.0, $y, $z);
          my $z2 = $Tak->($y - 1.0, $z, $x);
          my $z3 = $Tak->($z - 1.0, $x, $y);
          return $Tak->($z1, $z2, $z3);
        } else {
          return $z;
        } 
};

my $n = ($ARGV[0] || 0) - 1;
printf "Ack(%d,%d): %d\n",
        3, $n + 1, $Ack->(3, $n + 1);
printf "Fib(%.1f): %.1f\n",
        28.0 + $n, $Fib->(28.0 + $n);
printf "Tak(%d,%d,%d): %d\n",
        $n * 3, $n * 2, $n, $Tak->($n * 3, $n * 2, $n);
printf "Fib(%d): %d\n", 
        3, $Fib->(3);
printf "Tak(%.1f,%.1f,%.1f): %.1f\n",
        3.0,2.0,1.0, $Tak->(3.0,2.0,1.0);
[download]

gives a speed gain of roughly 25% - that's still slower than python, though...

update: fixed wording

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Please see Re^4: Are monks hibernating?. I've posted another version of Ack() towards the end.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

For speed you do have to go to C or assembler

You certainly don't have to drop that far. I certainly wouldn't entertain doing much of anything in a language that doesn't support automatic memory management.

Well, that was a 'turning of the knob' thing -- how fast do you need to go? Can you write the thing in Perl and thing do some performance analysis to find the hot spots, then code those bits in C to get the speed up?

Maybe that's a necessary penalty for the benefits of using a dynamic language, but even without jit, Java seems to do a whole lot better.

Perhaps, but Java just seems to be so clumsy and backwards to me -- I love the simplicity of C. You know exactly where you are at all times. If necessary, I'd probably build some OO routines and 'pretend' to do C++; just pass Container objects around that hold onto the collection of objects that I'm working on.

But this is a conversation that's tough to do over PM posts and morning coffee when it could be much more fun over a beer and face to face.

Java just seems to be so clumsy and backwards

I don't like Java either, though I place most of the blame for that on the horribly incestuous standard libraries. But the separate compiler/interpreter; distributable bytecode; and runtime performance are nice.

I'd probably build some OO routines and 'pretend' to do C++;

You should definitely take a look at D. It does automatic memory management, OO, hashes, delegates, mixins, Perl-style fors and a whole lot more, Think C++ without the mess and verbosity. C without the pain. And it's fast.

Now, if I could drop into Inline::D and transparently use Perl's hashes, objects and memory management...

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

For simple scripts of just a few lines of code, it matters that perl needs to load an executable of 1MB. Often, the load time is several times longer than the actual execution time. And that is something I just can't ignore.

That tends to suggest that you use a lot of short-lived, high-frequency (and possibly high-concurrency) and./or IO-bound apps? The archetypal example of which is dynamic http serving, though there are obviously many other server type applications that also fit the bill.

It's for this type of application that mod_perl/fastcgi are designed to alleviate exactly the problems you describe. It's not hard to see how a similar approach could be used for non-http applications that fit this mode of operation. A daemon app that runs perpectually in the background with all the relevant code loaded and a small, fast front-end that simply fires the parameters to the daemon and retrieves the results.

Most of my stuff runs in the exact opposite way. Long-lived and infrequently called apps performing cpu-intensive operations on large volumes of data and run for hours or days.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

PPerl or PersistentPerl are implementations of the daemonic approch you desribe.