Первая часть с выводами.

Как говорилось в первой части, большого смысла в оптимизации повседневного кода нет. Разумеется, я не призываю писать заведомо неудачные решения. Но и особо изгалаться тоже нет смысла. В подтверждение этому привожу историю оптимизации. Сразу оговорюсь, что можно было бы, например, генерировать новую таблицу,

Задача:
случайным образом перемешать ряды в таблице. Генерировать новую таблицу нельзя, необходимо использовать существующие узлы.

Возможные оптимизации

• Избегать использований liveCollection. А точнее: превращение liveCollection в массив. Гипотеза заключается в том, что так как liveCollection должна обновляться вместе с обновлением DOM, это приведет к дополнительным штрафам скорости. Разумеется, браузеры могут оптимизировать работу с liveCollection, но об этом еще предстоит узнать.
• Свести к минимуму обращения к DOM-у, как удаление, так и добавление узлов. Применение documentFragment и временное удаление узла из DOM-а.
• Использование documentFragment, как буфера для временного хранения отсортированных случайным образом рядов.
• Удаление на время из DOM-а, элемента, который содержит в себе перемешиваемы ряды. Теоретически должно произойти уменьшение количества обращений к DOM при удалении ряда.

Из этих вариантов я составил варианты их комбинаций и написал тесты на jspref.com и прогнал через имеющиеся браузеры. Ниже находится интерпретация полученных данных.

• Самое главное: нет подхода, который был бы самым быстрым для каждого браузера. Из этого следует следующее:
  • Оптимизируя код, не зная как он будет в последствии работать, можно сделать оптимальную версию для одного браузера, и неоптимальную для другого.
  • Изменение кода до неузнаваемости может не дать выигрыша в производительности
• Все браузеры медленно работают с liveCollection. Для выигрыша в производительности надо преобразовывать liveCollection в массив.
• Хрому и сафари не имеет значения, используется ли documentFragment и удаляется ли нод временно из DOM-а. Это говорит про оптимизированность методов, которые он применяет к обработке дома. Налицо несомненный плюс для пользователей, но с другой стороны есть эффект поощрения излишних DOM манипуляций со стороны непонимающих программистов (особенно, если они разрабатывают в хроме и не проверяют параллельно в других браузерах). Хотя это их проблемы.
• documentFragment играет важную роль в ускорении работы с DOM в ие.
• В фаерфоксе не оптимизирована работа с удаляемыми нодами. Временное удаление контейнера, содержащий удаляемыми строки, дает почти двукратное ускорение.

Итого
При работе с DOM-ом имеет смысл поменьше использовать liveCollection и побольше documentFragment. Остальные оптимизации будут давать неоднозначные результаты.