After posting my solution to 1161491 I had some 'free time' so I was playing.

My REPL which (can) time chunks of code for me automatically, produced some depressing numbers:

C:\test>p1
[0]{0} Perl> use Algorithm::Combinatorics qw[ permutations ];;
[0]{0.00943684577941895} Perl> $iter = permutations( [ reverse 1 .. 9 
+] );;

[0]{0.000318050384521484} Perl> printf "\r%s\t", join '', @$_ while de
+fined( $_ = $iter->next );;
123456789   
    
[0]{22.5874218940735} Perl>
[download]

22.5 seconds to generate 9! = 362880 permutations seemed longer than I would have expected; so then I wondered how much of that was down to the generation and how much the formatting and printing:

[0]{0} Perl>@d = permutations( [ reverse 1 .. 9 ] );;
[0]{2.31235218048096} Perl>

[0]{0} Perl> printf "\r%s\t", join '', @$_ for @d;;
123456789       
[0]{18.9919490814209} Perl>
[download]

So less than 2.5 seconds for the generation and almost 19 for the formatting and printing. (Leaving 1 second 'lost in the mix'.)

Of course, that one line for printing is doing rather a lot. Unpacking the contents of the anon arrays to a list; joining the list of digits into a string; and then interpolating that into another string before writing it out. So then I wondered about the cost of each of those elements of the task.

Looking at the code I saw that I could avoid 300,000 calls to each of join and printf by interpolating the lists from the array references directly into a string; provided I set $" appropriately:

[0]{0} Perl> $"=''; $_ = "@$_" for @d;;

[0]{1.93835282325745} Perl>
[download]

That was a nice saving, so then I thought about writing the output. Rather than use a loop: print for @d; which means calling print 300,000 times -- with all the calls into the kernel that involves -- why not join those 300,000 strings into a single string (one call to join) and the output it with a single call to print:

[0]{} Perl> $d = join "\r", @d;;

[0]{0.0442740917205811} Perl> print $d;;
123456789

[0]{4.72821307182312} Perl>
[download]

Summing the individual parts came out to ~10 seconds rather than the original 22.5. So let's put it all together and verify it:

[0]{0} Perl> $"=''; @d = permutations( [ reverse 1 .. 9 ] ); $_ = "@$_
+" for @d; $d = join "\r", @d; print $d;;
123456789
[0]{9.26112604141235} Perl>
[download]

Sure enough. Under 10 seconds; over 50% saved. Nice.

Can we go further?:

[0]{0} Perl> $"=''; print join "\r", map "@$_", permutations( [ revers
+e 1 .. 9 ] );;
123456789
[0]{10.0599029064178} Perl> 

[0]{0} Perl> $"=''; print join "\r", map "@$_", permutations( [ revers
+e 1 .. 9 ] );;
123456789
[0]{10.086268901825} Perl>
[download]

And the answer is no. Sometimes the elimination of intermediate variables -- especially intermediate arrays when the alternative is several long lists -- backfires.

Still. Another 5 minutes of 'idle time' waiting for another long simulation run occupied with an fun exercise, the lessons of which just might stay in my consciousness long enough to become influencial in the code I write in future.

A few otherwise idle minutes spent now, saving a few seconds on something that doesn't really benefit from that saving; that just might save me hours or days if the lessons happen to be applicable to my next project; or the one after that.

(If only I could apply those same level of savings to the simulation software I using -- open source, but I cannot compile it locally -- as perhaps then I would be lookng at a 20 hour wait for its completion rather than the 40+ I have in prospect :().