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

_>>Ну вот снова в этой темке получается один и тот же вывод: на C# можно написать удобно и получать тормозной код или неудобно и получать нормальный код. В C++ такой дилеммы в принципе нет — там является нормой одновременно и быстрый и удобный код. У это конечно есть своя цена (требуется определённая квалификация программиста), но компромисс между удобством и быстродействием точно не требуется.
S> Ну рассмешил!! Давно так не смеялся. И это говорит человек который использует Питон.

А что не так с Питоном? ) Он у нас позволяет очень удобно писать очень медленный код. Соответственно в тех случаях, когда подобное быстродействие приемлемо (например для скриптов), абсолютно логично использовать именно его. Так же как ты скажем используешь медленный 1C для всяких там бухгалтерий и т.п.

S> Еще раз в EF запросы кэшируются, так же как и на SQL. Если тебе это не нравится, то у тебя есть куча возможностей для оптимизации. Добавив всего одну или две лишние строки. В большинстве задач это и не нужно.

Это всё не то. Нужна предкомпиляция, а не кэширование.

S>http://www.codehint.ru/articles/2013-02-13_linq_entity_framework_5
S>

S>В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.

Фоновый поток для таких целей? ) Ужасы какие... Наверное ещё и с блокировками какими-нибудь? )))

S>Мало того, можно кэшировать результаты запросов
S>https://weblogs.asp.net/dotnetstories/using-second-level-cache-in-entity-framework-6-1-applications
S>https://github.com/loresoft/EntityFramework.Extended/wiki/Query-Result-Cache

А это всё вообще из другой области и для такого есть специализированные эффективные инструменты, а не подобное недоразумение.