Мины под производительностью ждут своего часа: часть 2

Ну не бывает в жизни «таблеток от всего», как и самоходных машин, одинаково хорошо ездящих, плавающих и летающих. В компьютерном мире кажущаяся простота использования готовых решений работает лишь постольку, поскольку существует и популяризируется чудовищная аппаратная избыточность для решения «обычного» класса задач. Как только вы подходите к чему-то, более-менее требовательному по одному из типов ресурсов (памяти, ЦП, I/O) — конечность производительности аппаратуры сразу чувствуется, а результат «копания чуть глубже» — показывает масштаб издержек, которыми заплачено за внешнюю простоту.

PS — я писал подобный логгер, который видя в БД BLOB-типы, выплевывал в лог что-то типа substring(X, 1, 256), чтобы не зафлуживать лог, и только будучи сконфигурированным на отдачу полного блоба (для детальной отладки), отдавал весь. И в БД-методы, которые отдают блобы, всегда добавляю параметр, типа InfoOnly, получив который, процедура не тянет из базы блоб, а для совместимости по резалтсету выдает convert(varchar(max), NULL) — так как часто достаточно получить метаданные (имя файла, размер, пользователя, контрольную сумму массива), без вытаскивания самого блоба с пластин диска

Воистину, JProfiler друг наш и мудрый наставник. Иногда такие неочевидности делает очевидными, что на 10 статей хватит :) Особенно на копиях данных с продакшенов.
Вот тоже, буквально на днях обнаружил с его помощью цепочку toArray->asList->toArray и так далее.