Hm. Do you see anything wrong with this usage that would prevent the in-place optimisation from kicking in?

perl -E"my @a; $a[$_]=rand for 1..1e6; <>; @a = sort @a; <>"
[download]

Because after the array is populated, memory usage stands at 42mb. After the sort, it jumped to 150MB.

Which admittedly is substantially better than:

perl -E"my @a; $a[$_]=rand for 1..1e6; <>; my @b = sort @a; <>"
[download]

Where it leaps from 42MB to 280MB. But it doesn't meet my idea of 'in-place'.

Do you see anything wrong with this usage that would prevent the in-place optimisation from kicking in?

Yes, you are allocating the values in @a as numbers, but as you compare then as strings they are converted to strings inside the sort and perl caches the string representation.

A little program to show the effect:

use Devel::Peek;

my @a = (1.1, 2.2);
print STDERR "allocated as:\n";
Dump \@a;

@a = sort { $a <=> $b } @a;
print STDERR "\nsorted as numbers:\n";
Dump \@a;

@a = sort @a;
print STDERR "\nsorted as strings:\n";
Dump \@a;
[download]

Under my particular OS/perl combination, stringifying a floating point number, increases its memory usage from 32 to 96 bytes.

A simple (an slow) workaround is to use two auxiliary variables for the comparison:

@a = sort { my ($b, $c) = ($a, $b); $b cmp $c } @a
[download]

I should've remembered about that :(