Каким образом производительность структуры сущностей 4 по сравнению с инфраструктурой сущностей 3.5?

Question

У меня есть один запрос на моей странице, выполнение которого занимает как минимум полсекунды с использованием EF 3.5. Когда я использовал хранимую процедуру, скорость была заметно выше. Это очень сложный запрос. Будут ли какие-либо улучшения производительности в предстоящем EF 4.0? И действительно ли EF 4.0 побеждает 3,5 производительности?

Answer 1

Краткий ответ: пока рано говорить. Парни .Net почти полностью сосредоточены на производительности, пока релиз 12 апреля не будет завершен и локализован. Кроме того, что подразумевается под быстрее? Быстрее можно посмотреть разными способами, например:

• В Entity Framework 4.0 появились новые функции , одни только улучшения отслеживания объектов могут означать огромные победы, поскольку вы сами не выполняете эту ручную работу ... в любом случае, по крайней мере, разработка будет быстрее. *
• Если раньше это не работало вообще, объекты с меньшим весом с поддержкой POCO могут означать гораздо меньшее смещение памяти при работе с большим количеством объектов. Независимо от того, насколько мала стоимость заполнения дополнительных свойств при извлечении из БД, существуют затраты как на их создание, так и на отслеживание (время загрузки и потребление памяти).

В вашем конкретном случае полсекунды - это длинное время для всего, кроме очень сложного или большого объема запроса ... вы смотрели, чтобы увидеть, сколько времени тратится в базе данных и сколько время потрачено один раз .Net есть данные? Если вы проводите большую часть своего времени вне SQL, тогда да, базовые улучшения в отражениях в Net 4.0 должны дать вам некоторое улучшение скорости ... однако, если вы проводите все свое время в SQL, это не сильно поможет совсем. Большая часть вашей проблемы с производительностью может быть индексацией сгенерированного SQL, а не производительностью Entity Framework.

Я бы следовал комментарию Кейна, посмотрел на SQL, который он генерирует для вашего запроса. Можно ли опубликовать это и хранимую процедуру, которая быстрая , чтобы мы могли найти причину проблемы?

Answer 2

Из блога ADO.NET :

Настройка запросов - добавлена ​​поддержка существующих операторов LINQ, распознавая больший набор шаблонов с LINQ, определение модели записи функции наряду со способностью использовать их в LINQ, и ряд другие способы создания и настройки запросы.

Улучшения читаемости SQL Generation - Улучшение удобочитаемость наряду с TSQL оптимизация производительности, из сгенерированные запросы, чтобы сделать это много проще понять что происходит

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

Однако маловероятно, что ORM когда-либо сможет выполнить запрос, который вы написали с нуля, так как он обслуживает так много разных сценариев, и, как правило, по умолчанию используется самый распространенный. Казалось, что EF 3.5 производил очень эффективный SQL для объединения, когда я его использовал, вероятно, лучшее, что я видел в ORM, так что есть надежда, что вы можете отказаться от SP в 4.0.

Если у вас есть хранимая процедура, я предполагаю, что это большой запрос - отправка этого SQL-текста каждый раз на сервер вызовет большой сетевой трафик, и это еще одна вещь, которую вы могли или не могли учитывать. Очевидно, что на том же сервере или в той же внутренней сети это оптимизация стиля «подстригись, чтобы похудеть».

Answer 3

Когда дело доходит до действительно сложных запросов, я не видел никаких доказательств того, что какой-либо из L2S, NH или EF может сгенерировать план запроса лучше, чем я в sproc. Мне нравятся ORM (особенно NH), но бывают случаи, когда время выполнения ORM может быть ограничено хорошо написанным sproc .