Производительность Linq to Entities и предварительное создание представлений

Первые запуски наших запросов linq to EF занимают много времени. Я был удивлен, не увидев разницы после предварительной генерации представлений. Я наткнулся на следующее утверждение в stackoverflow.

Генерация представления помогает только для «стандартных» запросов (например, когда вы вызываете someObject.RelatedEnd.Load() или MyContext.SomeSetName(). По понятным причинам это не помогает для специальных запросов с LINQ или ESQL. Используйте CompiledQuery для оптимизировать тех.

Когда он говорит «по очевидным причинам», я должен сказать: «Ну, для меня пока не очевидно». Если я правильно понимаю, он утверждает, что на запросы Linq to SQL не влияет предварительное создание представлений EF.

Я думал, что представления сущностей являются общими сопоставлениями между сущностями и таблицами и не имеют никакого отношения к какому-либо конкретному запросу. Это ошибка?

Я вижу огромное количество времени, используемого при первом запуске наших запросов Linq to Entities, и значительно меньшее время после этого, поэтому я предположил, что представления генерируются для соответствующих сущностей и таблиц. Если это не представление EF, которое можно предварительно сгенерировать, используя все время первого запуска, то что это?

Итак, мой вопрос состоит из трех частей:

  1. Создаются ли представления EF для каждого запроса или они просто связывают таблицы с сущностями независимо от сделанных запросов?

  2. Верно ли приведенное выше утверждение о том, что предварительное создание представлений EF не имеет значения для запросов Linq to EF? Нужно ли вместо этого использовать CompileQueries?

  3. Каковы «очевидные причины», упомянутые выше?

Примечание. Я бы даже не спрашивал, но в Интернете есть довольно много рекомендаций (включая msdn) для предварительного создания представлений, если вы используете EF. Это единственное место, где я видел, что если вы используете Linq to Entities, то предварительная генерация не имеет отношения к вашим запросам.


entity-framework entity-framework-6
person Community    schedule 24.02.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я не думаю, что ответ, который вы нашли, правильный. Вы можете думать о представлениях EF как о способе абстрагирования базы данных, чтобы EF мог выполнять свои функции, ничего не зная о фактической базе данных. Поэтому EF требует представлений для любого запроса или операции модификации, которая проходит через конвейер запроса/обновления EF. Фактически, любые/все запросы EF (будь то запросы Linq или запросы ESQL) строятся путем составления базовых запросов, которые на самом деле являются представлениями.

Чтобы ответить на ваши вопросы:

  • Представления генерируются только один раз, как правило, при первом запросе.
  • скомпилированные запросы и представления ортогональны - я объяснил представления выше, скомпилированные запросы касаются кэширования сгенерированного SQL для запроса, чтобы избежать повторной компиляции запроса. Это помогает, поскольку обычно набор запросов, используемых в приложении, ограничен, поэтому сгенерированный SQL можно кэшировать (обратите внимание, что если вы передаете параметры в запрос, это не влияет на сгенерированный SQL, поскольку он также будет параметризован). Начиная с EF5, кэширование происходит автоматически (http://blogs.msdn.com/b/efdesign/archive/2011/06/30/auto-compiled-linq-queries-entity-framework-june-2011).-ctp.aspx).

В EF6 был внесен ряд улучшений в создание представлений. Я бы сказал, что в подавляющем большинстве случаев вам вообще не нужно использовать предварительно сгенерированные представления с EF6 (и я говорю это как автор статьи шаблоны T4 для создания представлений для EF5 и EF6, а также интерактивные представления для EF6). Однако мы обнаружили, что для приложений Code First в EF6 фактическим узким местом было построение модели. Также было несколько других проблем с производительностью — см. эту запись в блоге для более подробной информации. Многие из этих проблем были исправлены в EF6.0.2, поэтому, если вы еще не обновились до EF6.0.2, вам следует это сделать. Я думаю, что в EF 6.1 появится еще несколько исправлений, связанных с производительностью.

Примечание: обратите внимание, он сказал LINQ or ESQL, а не Linq to SQL. ESQL — это SQL-подобный язык запросов, поддерживаемый EF. Если вам интересно, вы можете прочитать больше здесь. Поскольку EF имеет хорошую поддержку LINQ, на самом деле не так много сценариев, в которых вы хотели бы использовать ESQL, а не Linq to Entities. Linq to SQL не связан с EF/ESQL/Linq to Entities.

person Pawel    schedule 25.02.2014
comment
Это очень актуально для меня, так как я использую наследование TPH для дочернего класса, состоящего из свойств сложного типа. Предварительно созданные представления дочернего класса не влияют на начальное время загрузки, которое может составлять 40 секунд. Последовательные загрузки занимают 0,5 сек. Я использую EF5. Да, я думаю об обновлении до EF6, но меня беспокоит тот факт, что среда выполнения EF6 теперь сама требует Jitter при первом запуске. - person SamJolly; 28.11.2014