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

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

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

_>Эээ что? ) Какой парсинг, какого текста? )
Если ты читал мои статьи, то там названия полей могут быть отличными от полей в Базе. Кроме того там могут применяться объектные запросы.

Кроме того в Linq to EF можно использовать Entity SQL

Например

var str = @"Select VALUE  p From [Спр_Номенклатура] as p";

           var Запрос = qr.CreateQuery<Справочник.Номенклатура>(str );

           var res = Запрос.Execute(MergeOption.NoTracking);

 

           foreach (var элем in res)

            {

                Console.WriteLine("{0}.{1} - {2}", элем.Наименование.TrimEnd(), элем.Артикул, элем.ПолнНаименование.TrimEnd());

            }

Но по большому счету выхлоп от него небольшой



https://msdn.microsoft.com/ru-ru/library/bb738573(v=vs.110).aspx
Отличия Entity SQL и Transact-SQL

Идентификаторы
В языке Transact-SQL сравнение идентификаторов всегда осуществляется с учетом параметров сортировки текущей базы данных. В Entity SQL идентификаторы всегда чувствительны к регистру и диакритическим знакам (то есть Entity SQL различает диакритические знаки, например, «а» отличается от «?»). Entity SQL обрабатывает версии букв, которые кажутся такими же, но являются другими символами и происходят из других кодовых страниц. Для получения дополнительной информации см. Набор символов ввода (Entity SQL).
Функциональность Transact-SQL, недоступная в Entity SQL
Следующая функциональность Transact-SQL недоступна в языке Entity SQL.
DML
В настоящее время язык Entity SQL не поддерживает инструкции DML (вставка, обновление, удаление).
DDL
Текущая версия Entity SQL не поддерживает DDL.
Командное программирование
Язык Entity SQL не поддерживает командное программирование в отличие от Transact-SQL. Используйте вместо этого языки программирования.
Функции группирования
Язык Entity SQL пока не поддерживает функции группирования (например, CUBE, ROLLUP и GROUPING_SET).
Функции аналитики
Язык Entity SQL не предоставляет (пока) поддержку функций аналитики.
Встроенные функции, операторы
Язык Entity SQL поддерживает подмножество встроенных функций и операторов Transact-SQL. Вероятно, эти операторы и функции будут реализованы ведущими поставщиками хранилищ. В языке Entity SQL используются специальные функции для хранилищ, объявленные в манифесте поставщика. Кроме того, модель Entity Framework позволяет объявлять встроенные и пользовательские функции хранилища для использования в Entity SQL.
Подсказки
Язык Entity SQL не предоставляет механизм подсказок в запросах.
Пакетирование результатов запроса
Entity SQL не поддерживает пакетирование результатов запросов. Например, допустим следующий запрос Transact-SQL (отправляемый как пакет):


select * from products;

select * from catagories;

Однако эквивалент Entity SQL не поддерживается.
Select value p from Products as p;
Select value c from Categories as c;
Entity SQL поддерживает только запросы, которые выдают один результат на одну команду.

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

_>Да что ты говоришь. ))) Ну вот например мы сейчас находимся на форуме. Он работает на основе sql БД (более того, он даже на linq2sql написан, но это к делу уже не относится). И в каких же местах по твоему тут нужны динамические запросы? )
Угу. На этом форуме не так много запросов. С таким объемом и 1С прекрасно справляется. Система оооочень прочтая.

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

_>Вообще то гугл и ему подобные — это уже следующие уровень, на котором sql БД уже не используются. А мы обсуждаем что-то средненькое, пока ещё с sql, но уже не домашнюю страничку васи пупкина.

Со средненьким и 1С прекрасно справляется.

S>>На самом деле прошу прощения. До конца не просмотрел запрос
S>>select new { o.OrderID, o.OrderDate, c.Country, c.CompanyName }
S>> ).Take(500).ToList();
S>>Здесь никакого поиска по Кэшам, так как возвращается анонимный класс. Но можно было бы сравнить с применением CompiledQuery.Compile
S>>https://msdn.microsoft.com/ru-ru/library/bb399335(v=vs.110).aspx
S>>И посмотреть где идет задержка.

_>Нуу вперёд, всем будет любопытно посмотреть на ещё варианты замеров) Только не забудь брать за базу вариант на ADO.NET. )))

Да на самом деле мне интересно, как меняется скорость от версии к версии. А вот насчет скорости, то берем и считаем стоимость и скорость разработки, стоимость поддержки. Считаем стоимость железа для поддержки необходимой производительности.
Могут быть трех звенки, двух звенки и гибриды того и другого. Вот кому платит за это и должно быть интересно.
Например на 1С там трех звенка и её можно разнести по кластерам. Но зато там мегабайты кода, но интерпретатор.