Ну то что вы не видите проблем в DBIx::Class просто говорит что характер вашей работы не содержит никаких ресурсоемких задач которые должны работать быстрее. Обычно говорят что у вас нету хайлоада, но этот термин так испоганили что сейчас это слово больше bullshit-маркер. То есть вы не работаете плотно с DBIx::Class и в вашей практике не было проблем, например, вытащить через него 100К строк с пост обработкой.
Например в свое время я проводил сравнение - как можно быстрее вытащить данные из PostgreSQL в csv таблицу... Шло в ход все... Результат меня удивил... Перенос коннекта к БД в Си и работа с данными там-же ускоряет выполнение запроса в 5 раз. Это оверхед Перла. Фактически большую часть времени выполнения запроса на получение данных уходит на двойную трансформацию данных: В мир перла и потом в фаил. Это простейший пример, который, кстати, разбивает ваше утверждение что вы тупите в базе. Вы можете тупить в преобразовании в Перле. И это при том что XS часть DBD::Pg написана довольно хорошо. Я туда лазил и читал все это.
100к строк и в csv - да, тут имеет глубочайший смысл переливать в CSV средствами БД, благо она умеет.
Если я вижу, что какая-то страница начинает выполняться недопустимо долго, я начинаю профилировать с SQL-запроса, и в моей практике этого профилирования (один раз, да, три дня рефакторил наскоро накиданное когда-то view) всегда хватало.
Еще раз, для закрепления:
В большинстве случаев, усилия по оптимизации следует уносить с миддла на БД. Потому, что потребление мидла соотносится с потреблением БД где-то как 1:5-1:10. Соответственно получается и плечо эффективности. Ускорение запроса к БД на 10% ускоряет обработку ответа на 9%, ускорение мидла на 10% - на 1%. Да, бывают случаи, когда идет борьба за каждую миллисекунду запроса и заливка железом - не ответ, но в целом - совершенствуйте БД, и будет счастье.
