Здравствуйте, alex_public, Вы писали:

_>Так и есть. Фанаты linq что тогда были неадекватные, что сейчас. В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии.

У тебя linq синоним EF. Есть два разных бенчмарка. В одном указано, что linq2db на порядок или два быстрее EF, и почти такой же быстрый, как и ADO. В другом — тоже самое про dapper.
Из этого ты делаешь вывод, что dapper быстрее любого linq-провайдера на том основании, что он быстрее EF.

Где логика ?

Здравствуйте, alex_public, Вы писали:

_>Так и есть. Фанаты linq что тогда были неадекватные, что сейчас. В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии.

У тебя linq синоним EF. Есть два разных бенчмарка. В одном указано, что linq2db на порядок или два быстрее EF, и почти такой же быстрый, как и ADO. В другом — тоже самое про dapper.
Из этого ты делаешь вывод, что dapper быстрее любого linq-провайдера на том основании, что он быстрее EF.

Где логика ?

Ты ухитрился слить 2 разных высказывания в одно
а. даппер лучше любого linq-провайдера
б. даппер есть наилучший способ эффективно использовать DBMS

Вот здесь есть противоречия:
1 Нулевой оверхед на сервере совершенно не означает наилучшее использование сети между сервером и базой данных
2 Нулевой оверхед на сервере совершенно не означает наилучшее использование самого движка базы данных

То есть, ты пытаешься оптимизировать исключительно вызывающий код, без оглядки на самую важную вещь.

Почему даппер в SO показал хороший результат, очевидно — ручные оптимизации проблем 1 и 2 и очень, очень, очень простая, тривиальная модель — форум.