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

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

_>>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.
S>> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.

_>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).
Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/

_>>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
S>> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.

_>Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция.
На самом деле нужно в основном динамические запросы строить особенно интерактивные.

S>>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.
S>> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.

_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
Опять же если хочешь сравнивать, то нужно их сравнивать правильно, в том числе и на сложных запросах с группированием данных в иерархии.
Опять же отображения на объекты нужны для редактирования. Обычные запросы как правило возвращают ID,Наименование и прочие поля. Да там тоже идет отображение на аноноимные типы, но не нужно отслеживать кэши и изменения.

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

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

_>>>Ну так это же только EF касается и всё. Для других измеренных инструментов ничего подобного не требуется. Более того, даже если говорить о EF, то там же можно увидеть сравнение EF в режиме linq и sql, в котором этот нюанс опять же не будет играть никакой роли.
S>> Кто сказал? В режиме SQL тоже идет отображение. Никакой разницы нет.

_>Именно про это я и сказал. Т.е. раз отображение идёт везде, то вся разница между измерением EF с linq и EF с row sql идёт за счёт тормозов обработки linq. Можешь сам вычислить эту разницу по данным графикам. Да, и кстати... Если убрать тормоза от трекинга в EF, то в процентном отношение накладные расходы от linq будут выглядеть только хуже (т.к. они не изменятся, а общее время запроса уменьшится).
Там тоже идет парсинг текста . Посмотри статью http://infostart.ru/public/393228/

_>>>Свобода есть везде. Нужна не свобода, а готовый удобный инструмент. Если ты можешь продемонстрировать мне инструмент для .net, позволяющий удобно работать со статически типизированным sql без затормаживания (ну скажем накладные расходы не более нескольких процентов относительно варианта с голыми sql строками) системы, то это будет аргументом. А всё остальное — это пустая болтовня.
S>> Так вот твой инструмент не может строить динамических запросов в ран тайме. А это как правило основные запросы.

_>Вообще то может (было бы смешно иначе, суметь сделать сложное и не суметь простое), хотя это и не часто необходимая функция.
На самом деле нужно в основном динамические запросы строить особенно интерактивные.

S>>Сравниваем скорость разработки, в том числе и интерактивное изменение данных. Вот пока действительно ты даже инструмент не держал в руках, но осуждаешь.
S>> Еще раз у большинства нет нареканий на скорость 1С. Главное скорость разработки и порог вхождения. А с оверхедами от версии к версии избавляются.

_>А причём тут вообще бухгалтерский софт, когда мы обсуждали высоконагруженные сервисы? ) Естественно, что на современных компьютерах одиночный запрос в БД не будет тормозить, даже если он генерируется на bash'e. ))) Но это не значит, что тебе удастся написать на bash'e сайт с нормальной посещаемостью.
1С это не только бухгалтерия, но и 1С:ERP, производство где нагруженность большая.
То о чем ты говоришь это типа Гугла, то там и Linq не нужен. Linq нужен где нужно писать тонны кода. И вот здесь во главе угла уже скорость разработки.
Опять же если хочешь сравнивать, то нужно их сравнивать правильно, в том числе и на сложных запросах с группированием данных в иерархии.
Опять же отображения на объекты нужны для редактирования. Обычные запросы как правило возвращают ID,Наименование и прочие поля. Да там тоже идет отображение на аноноимные типы, но не нужно отслеживать кэши и изменения.

На самом деле прошу прощения. До конца не просмотрел запрос

select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
).Take(500).ToList();
Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile

https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx

И посмотреть где идет задержка.