Размышляя над результатами наших тестов, обратите внимание и на тот факт, что все они проводились на неупорядоченных массивах, сортировка которых наиболее ресурсоёмка. На практике очень часто встречается ситуация, когда требуется лишь восстановить слегка нарушенный (скажем, добавлением новых элементов) порядок. В таких случаях сортировка может оказаться менее ресурсоёмка и экономия времени от выноса кода за пределы блока оператора sort будет ощущаться на массивах, размеры которых больше.

Есть ещё одно существенное соображение. Вы видели, что при работе с большими списками код из листинга 11 более производителен, чем код из листинга 10. Однако промежуточный массив, возникающий при работе листинга 10, позволил бы весьма гибко выполнять самые разные сортировки (конечно, если бы мы его сохранили подобно тому, как мы это сделали в листинге 7 при создании двух сортированных массивов). Например, мы могли бы сортировать список версий по возрастанию версии, но убыванию подверсии. То есть, совершенствуя наше решение, мы снизили его универсальность, которая могла бы оказаться полезной в каких-то ситуациях.

Одним словом, абсолютно универсального решения не существует. Каждый подход хорош только в определённых условиях. Если вы намерены всерьёз позаботиться о производительности своего кода, то я посоветовал бы ознакомиться со страницами руководства perldoc Benchmark и всегда тестировать свой код. Причём тестирование, как вы уже убедились, следует проводить в условиях максимально «приближенных к боевым».