Метод IQueryable Count требует больше времени для выполнения

Question

С WCF, построенным поверх БД, содержащей около 200 таблиц, и Entity Framework, первое время после входа в WCF занимает много времени (около 2 минут).

Вступление в код показало, что виновником является метод IQueryable.Count.

Это происходит только в первый раз после построения кода WCF. Последовательное выполнение метода Count выполняется быстро, как и ожидалось.

В чем может быть причина? Делают ли сущности какое-то фоновое кэширование вида после перестройки кода?

Пожалуйста, поделитесь своими мыслями!

ОБНОВЛЕНИЕ:

@ Крейг: Спасибо за предварительную генерацию просмотров ссылка

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

Также ознакомьтесь с Lazy Loading for EF library .

Answer 1

Это известная проблема, которая будет решена с помощью .NET 4.0 .

При первом запуске веб-приложения код должен быть кэширован. С этого момента он работает на полной скорости. В статье показаны текущие методы предотвращения этого начального замедления путем предварительного запуска кода до того, как ваш первый пользователь подключится к службе.

Answer 2

Ответ Хромой утки полезен (с положительным голосом), но он не рассказывает полную историю. При первом выполнении запроса Entity Framework происходит несколько вещей. Одним из них является создание представления, где SQL компилируется для общих запросов, таких как загрузка наборов сущностей и загрузка отдельных сущностей. Но генерация представления также может быть выполнена во время компиляции , что спасает первого, не повезло, человека, запустившего запрос, с повышением производительности этого шага. Этот шаг повторяется всякий раз, когда инициализируется новый ObjectContext, поэтому небольшие накладные расходы на создание представления во время компиляции сильно окупаются во время выполнения. Второй - это компиляция IQueryable в каноническое дерево команд, которое можно оптимизировать с помощью CompiledQuery . Возможно, вы столкнулись с одной или обеими из этих проблем, поэтому, прежде чем списывать их как проблему .NET 3.5 SP 1, стоит их проверить.