Curious. Are you sure your benchmark and real code are running under identical conditions? The code you posted should have similar behavior. If you are under severe memory or cpu pressure from other processes, that would explain the very long real times. (The actual cpu time elapsed can be much shorter than real time.) If this is a piece of some other program (daemon), have you checked the nice level?

The only other thing I can think of is your optimization to pre-expand @temp. (The call to _fact is just an optimization, yes?) If you do that incorrectly your @temp array may be much larger than it is supposed to be. Have you checked the size of @temp?

I've made some assumptions by looking at your code, and here is a complete example:

use strict;
use warnings;

use Algorithm::Permute qw(permute);

my ($n,$i,@n,@temp,%arrangements);

$n = 8;        @n = (1..$n);
$i = 0;        $temp[&_fact($n)-1] = 1; # _fact := n!

$|++;
permute { $temp[$i++] = join(',',@n) } @n;
print STDERR scalar(localtime),$/;
@arrangements{@temp} = undef;
print STDERR scalar(localtime),$/;

sub _fact {
    my($n) = @_;
    my $t = 1;

    while ($n > 1) {
        $t *= $n;
        --$n;
    }

    $t
}
[download]

Running on an Athlon 700, 256MB RAM with Linux 2.2, I see this output:

red.vulpes.com:~% perl test.pl
Mon Sep 30 16:49:39 2002
Mon Sep 30 16:49:40 2002
red.vulpes.com:~% perl -v

This is perl, v5.8.0 built for i686-linux-thread-multi
...
[download]