Re^6: In-place sort with order assignment

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'.

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.

Comment on Re^6: In-place sort with order assignment Select or Download Code

Replies are listed 'Best First'.
Re^7: In-place sort with order assignment by salva (Canon) on Sep 20, 2010 at 08:54 UTC
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]	[reply] [d/l] [select]
Re^8: In-place sort with order assignment by BrowserUk (Patriarch) on Sep 20, 2010 at 12:10 UTC
I should've remembered about that :(	[reply]