The arrays I would be using are not fixed in length, so the number of possible orderings will be HUGE

Then I strongly suggest Permuting with duplicates and no memory as most of the other permutation implementations I've run into insists on generating all of the permutations and then returning them in one big list (though, Algorithm::Permute doesn't have that problem).

I also notice you mention "unique" which makes me think that you might have cases where $a eq $c and want that accounted for in the generation of the permutations. This is another thing that my snippet handles that most permutation generators don't (and Algorithm::Permute doesn't handle that).

Finally, you mentioned speed. I haven't run benchmarks (and would be interested in see some), but I suspect that the object overhead of Algorithm::Permute might be a disadvantage here.

Just thought the comparisons might be helpful.

I'm using your snippet because it's easier on the memory, nice algorithm too (++ for that) ... but isn't it slower because it keeps going through the entire list? (I haven't looked at the code in Algorithm::Permute though)

Well, saying 'unique' might have been confusing because what I meant was that none of the newly sorted lists should be the same. All of the elements are different anyway.
Shows that my english needs improvement.

Thanks everyone for the help, I really appreciate it.
CBAS.