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

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

_>·>Да и вообще, я же отвечал в контексе высказываний alex_public, типа "раз рефлексия занимает время >0, то значит она источник тормозов". Нет, жаль, конечно, но не значит... ах как бы всё было просто тогда.

_>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. )))
Ну дык приведи главный источник тормозов Linq. Мне самому интересно.
И еще интересно как та в EF 7/ Тоже интересно. Ты же эксперт.

Кстати не обязательно будет вообще рефлексия
https://msdn.microsoft.com/Ru-ru/data/hh949853.aspx

При первом выполнении запроса он проходит через внутренний компилятор плана для перевода концептуального запроса в команду хранилища (например, в инструкцию T-SQL при работе с SQL Server). Если кэширование плана запросов включено, то при следующей отправке запроса команда хранилища извлекается непосредственно из кэша плана запросов, минуя компилятор плана.

Кэш плана запросов совместно используется всеми экземплярами ObjectContext внутри одного домена приложения. Нет необходимости хранить экземпляр ObjectContext для получения преимуществ от кэширования плана запросов.

3.2.1. Некоторые замечания о кэшировании плана запросов
Кэш плана запросов совместно используется для всех типов запросов: Entity SQL, LINQ и объектов CompiledQuery.
По умолчанию кэширование плана запросов включено для запросов Entity SQL, выполняемых и через EntityCommand и через ObjectQuery. В EF 5.0 оно также по умолчанию включено для запросов LINQ. Кэширование планов запросов можно отключить, задав для свойства EnablePlanCaching (в EntityCommand или ObjectQuery) значение false.

Изменение значения параметра в параметризированных запросах не помешает извлечению нужных результатов из кэша. Однако изменение аспектов параметра (например, размер, точность и масштаб) приведет к извлечению другой записи из кэша.
При использовании Entity SQL строка запроса является частью ключа. Любое изменение запроса приведет к получение других записей из кэша, даже если запросы функционально эквивалентны. Сюда относится и изменение регистра, и пробелы.
При использовании LINQ из запроса формируется часть ключа. Изменение выражения LINQ приведет к созданию другого ключа.
Могут действовать и другие технические ограничения, дополнительные сведения см. в разделе Автоматические компилируемые запросы.

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

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

_>·>Да и вообще, я же отвечал в контексе высказываний alex_public, типа "раз рефлексия занимает время >0, то значит она источник тормозов". Нет, жаль, конечно, но не значит... ах как бы всё было просто тогда.

_>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. )))
Ну дык приведи главный источник тормозов Linq. Мне самому интересно.
И еще интересно как та в EF 7/ Тоже интересно. Ты же эксперт.

Кстати не обязательно будет вообще рефлексия
https://msdn.microsoft.com/Ru-ru/data/hh949853.aspx

При первом выполнении запроса он проходит через внутренний компилятор плана для перевода концептуального запроса в команду хранилища (например, в инструкцию T-SQL при работе с SQL Server). Если кэширование плана запросов включено, то при следующей отправке запроса команда хранилища извлекается непосредственно из кэша плана запросов, минуя компилятор плана.

Кэш плана запросов совместно используется всеми экземплярами ObjectContext внутри одного домена приложения. Нет необходимости хранить экземпляр ObjectContext для получения преимуществ от кэширования плана запросов.

3.2.1. Некоторые замечания о кэшировании плана запросов
Кэш плана запросов совместно используется для всех типов запросов: Entity SQL, LINQ и объектов CompiledQuery.
По умолчанию кэширование плана запросов включено для запросов Entity SQL, выполняемых и через EntityCommand и через ObjectQuery. В EF 5.0 оно также по умолчанию включено для запросов LINQ. Кэширование планов запросов можно отключить, задав для свойства EnablePlanCaching (в EntityCommand или ObjectQuery) значение false.

Изменение значения параметра в параметризированных запросах не помешает извлечению нужных результатов из кэша. Однако изменение аспектов параметра (например, размер, точность и масштаб) приведет к извлечению другой записи из кэша.
При использовании Entity SQL строка запроса является частью ключа. Любое изменение запроса приведет к получение других записей из кэша, даже если запросы функционально эквивалентны. Сюда относится и изменение регистра, и пробелы.
При использовании LINQ из запроса формируется часть ключа. Изменение выражения LINQ приведет к созданию другого ключа.
Могут действовать и другие технические ограничения, дополнительные сведения см. в разделе Автоматические компилируемые запросы.

Там же

Наши тесты показали, что применение CompiledQuery может дать 7 % прироста по сравнению с запросами LINQ. Это означает, что при выполнении кода из стека Entity Framework будет затрачено на 7 % меньше времени. Это значит, что ваше приложение будет на 7 % быстрее. В целом затраты на написание и поддержку объектов CompiledQuery в EF 5.0 могут быть выше, чем получаемый от них прирост производительности. Впрочем, ваши результаты могут быть другими, поэтому используйте этот подход, если вашему проекту требуется дополнительная производительность.

Дополнительные сведения о создании и вызове CompiledQuery см. в разделе «Скомпилированные запросы (LINQ to Entities)» документации MSDN: http://msdn.microsoft.com/library/bb896297.aspx.

Есть два момента, которые нужно учитывать при применении CompiledQuery — использование только статических экземпляров и проблемы с их компоновкой. Далее дается подробное описание этих двух моментов.