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

_>>Там не 56 микросекунд на запрос. ))) Посмотри исходник теста. Это ещё одна милая особенность теста от IT (в дополнение к неэффективному использованию ADO): указано суммарное количество полученных из БД строк, а не количество запросов. ))) Если же ты, посмотрев исходник, вычислишь реальное время запроса, то увидишь, что оно довольно приличное (скажем заметно больше, чем в обсуждаемых тут в начале тестах). Что вполне логично для не самого тривиального запроса, исполняемого на отдельной машине.
I>Это не важно. Ты порядок цифр серелизации/десерелизации xml, json представляешь ? А сколько времени работает сам веб-стек ?

Это как раз важно. А вот упомянутые тобой вещи — это вообще смешные задачи на фоне работы выполняемой БД. Ты сам то хоть пробовал замерять время преобразования из/в json на современном гигагерцовом процесссоре? ))) Там будут цифры за пределами всего обсуждаемого тут. )))

I>То есть, если приложение будет висеть в ожидании на милисекунду меньше, тебя это категорически расстраивает ?

У тебя изначально не верный подход к анализу вредности накладных расходов. Правильный подход такой: фиксируем и нагрузку и время отклика и дальше смотрим насколько меньше денег на железо нам можно будет потратить, в случае устранения данных накладных расходов.

I>Веб, который веб, как раз висит в ожидании ответа БД. Потому непринципиально как долго формируется запрос, милисекунду больше, или милисекунду меньше. Здесь вообще нормой является EF, потому что висение в ожидании все равно перевешивает даже такие тормоза.

Если уж говорить про норму (как самое распространённое) в веб'е, то уж точно будет не что-то из .Net'а, а скорее какой-нибудь там PHP. ))) Ну и да, там тоже есть множество своих ORM, естественно без всяких специальных статических языков запросов.