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

_>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.
S> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.

Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).

_>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
S> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.

Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция.

S>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.
S> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.

А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.