Существуют-ли какие-то данные о производительности EF в сравнении с хранимками? Я могу сделать свои собственные тесты, но возможно это уже кем-то сделано. На данный момент проект который мы делаем с его помощью не отличается заметной производительностью, и по-видимому часть ответственности за это лежит на EF.
Причем я не имею ввиду какие-то моменты где EF используется неправильно или неоптимально, интересует именно то, насколько EF медленнее в обычных запросах написанный "правильно" с точки зрения EF. Под обычными имеются ввиду запросы с несколькими джойнами, апдейты и инсерты в несколько таблиц.
Дополнительный вопрос про память отьедаемый им на сервере, при загрузке контекста от сжирает гиг памяти сервера, это нормально?

hVosttКратко: хранимки быстрее.

Неизвестно, какие конкретно запросы вы собираетесь сравнивать. EF бы на свет не появился и дожил до наших дней, если бы овчинка не стоила бы выделенки.

Сравнивать пытаюсь типичные запросы, с несколькими джойнами к примеру и компилированием из этого нужного класса.

hVosttСкорее всего ответственность лежит на неправильном употреблении EF. Это самая распространённая проблема. EF конечно накладывает определённый оверхед и по памяти и по скорости, но обычно этим можно пренебречь.

А какой именно оверхэд? Я понимаю что все условно, но на сферическом сервере в вакууме сколько этот оверхэд получится на типичном запросе, 5 миллисекунд, 100 миллисекунд, полсекунды?


hVosttЕсли делаете запросы на получение данных, пишите проекции. Основная проблема тех, кто осваивает EF — они не пишут проекции. Не умеют их писать. Не понимают что это такое. Отсюда растут ноги всех проблем. Особенно SELECT N+1.

Я предполагаю что запрос написан правильно, т.е. никаких вытягиваний из базы лишних вещей и 100 запросов вместо одного. Условно есть запрос, который исходит от EF и я точно такой-же сложу в хранимку, которую вызову через ADO и замаплю на свой класс вручную. Какой примерно оверхэд и в каком именно месте появится, скажем создание контекста и прочие вещи которые EF будет делать. Предположим также что количество таблиц большое, несколько сотен с десятками полей в каждом (если вдруг это влияет как-то на контекст т.к. как я вижу все эти классы там есть).
В ADO вызов хранумки происходит быстро и просто, а вот чем именно EF занимается пока не совсем ясно.


hVostt EF бы на свет не появился и дожил до наших дней, если бы овчинка не стоила бы выделенки.

Основная цель EF это-же упрощение маппинга на классы, он это делает и поэтому овчинка до сих пор жива, но меня интересует сколько именно в граммах мы теряем производительности на этом