Здравствуйте, gandjustas, Вы писали:
G>По ссылке время замеряется вместе с инициализацией контекста\открытием соединения, а у тебя — только время запросов.
Если внести открытие соединения в замер, то получится ~2%. Но никак не 90%. К тому же открытие соединения измерять не совсем верно, т.к. множество запросов на одном соединении — обычное дело.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alex_public, Вы писали:
_>Ну так и для Linq никто в этой теме так и не смог привести примера, где join'ы меняются в зависимости от вида СУБД.
Это видимо потому что когда тебе приводятся примеры, то ты их благополучно игнорируешь.
Держи:
-- DB2 DB2.LUW DB2LUWSELECT
(
SELECT
"t1"."ParentID"
FROM
"Child" "t1"
WHERE
"t2"."ParentID" = "t1"."ParentID"
FETCH FIRST 1 ROWS ONLY
) as "c1"
FROM
"Parent" "t2"
WHERE
(
SELECT
1
FROM
"Child" "t3"
WHERE
"t2"."ParentID" = "t3"."ParentID"
FETCH FIRST 1 ROWS ONLY
) IS NOT NULL-- PostgreSQL PostgreSQL.9.3 PostgreSQLSELECT
t2."ParentID" as "ParentID1",
t2.c1 as c11
FROM
"Parent" t3
LEFT JOIN LATERAL (
SELECT
t1."ParentID",
1 as c1
FROM
"Child" t1
WHERE
t3."ParentID" = t1."ParentID"
LIMIT 1
) t2 ON 1=1
WHERE
(
SELECT
1
FROM
"Child" t4
WHERE
t3."ParentID" = t4."ParentID"
LIMIT 1
) IS NOT NULL
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, gandjustas, Вы писали:
G>>По ссылке время замеряется вместе с инициализацией контекста\открытием соединения, а у тебя — только время запросов.
IT>Если внести открытие соединения в замер, то получится ~2%. Но никак не 90%. К тому же открытие соединения измерять не совсем верно, т.к. множество запросов на одном соединении — обычное дело.
Видимо на локальной базе накладные расходы на передачу по сети меньше, поэтому и разница столь значительна.
Здравствуйте, IT, Вы писали: IT>Тут нужно с самими тесами разбираться. Я вообще не соображу как там время на создание коннекшина замеряется.
Они выполняют один реквест в соединении, потом два реквеста, и решают систему линейных уравнений t1=t0+tR, t2=t0+2*tR
Зная t1 и t2 выводят t0 = 2*t1 — t2
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IT, Вы писали:
_>>Ну так если ты настаиваешь, что 5% — это самый большой возможный уровень накладных расходов у linq2db, то как ты тогда объясняешь 90% в данном http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html тесте (случай Simple TOP 10 query)?
IT>Это объясняется тем, что я вообще не понимаю что тестируют эти тесты. Вот мой тест:
А ты не мог бы померять total ? Примерно так:
static void Main(string[] args)
{
LinqTest();
AdoTest();
var sw = new Stopwatch();
sw.Start();
var n = LinqTest();
sw.Stop(); Console.WriteLine("LINQ: {0} in {1}", n, sw.Elapsed);
sw.Reset();
sw.Start();
n = AdoTest();
sw.Stop(); Console.WriteLine("ADO: {0} in {1}", n, sw.Elapsed);
}
Пудозреваю, именно здесь якобы и есть те самые 90% о которых вещает alex_public
Здравствуйте, Sinclair, Вы писали:
S>Они выполняют один реквест в соединении, потом два реквеста, и решают систему линейных уравнений t1=t0+tR, t2=t0+2*tR
Один или два реквеста в тестах — это точность примерно на уровне статистической погрешности. Чтобы более менее что-то измерить нужны тысячи итераций, а лучше миллионы.
Если нам не помогут, то мы тоже никого не пощадим.
Ещё раз попытаюсь объяснить где у LINQ могут быть тормоза и насколько они влияют на общую картину.
Что происходит во время LINQ запроса:
1. Компилятор генерирует код для построения ExpressionTree, соответственно при вызове кода оно строится каждый раз при каждом вызове. Т.е. у нас уже появляются накладные расходы, с которыми вообще ничего нельзя поделать. Насколько они влияют на общее время зависит от сложности запроса, но мы видели, что всё в сумме болтается в районе 1%.
2. Далее управление принимает LINQ провайдер, который по полученному ET строит SQL. Здесь всё зависит от радиуса кривизны рук разработчиков. Процесс разбора ET и построение оптимального SQL действительно может оказаться дорогостоящим и самое главное плохо кешируется. Но сильно заметно это только либо на совсем убитом провайдере, либо на очень простых запросах как в тестах, где к томуже полностью исключён код окружения запроса типа стэка ASP.NET, авторизация, логирование, рендеринга и всех остальных прелестей. Тем не менее некачественный LINQ провайдер может здесь существенно натормозить.
3. После построения SQL и его выполнения производится материализация объектов. Вот здесь медленный маппинг может дать замедление в разы при условии, что сам запрос к БД оптимален.
В результате, чтобы получить реально полезную картинку соотношения производительности нужно тестировать не отдельные запросы, а весь стек приложения. Т.е., например, для веб-приложения подёргать странички с разными вариантами запросов. Тогда будет видно, что вменяемый LINQ провайдер даёт замедление на уровне погрешности, а невменяемый заметно тормозит.
Я не говорю, что подобные тесты совсем не нужны, нужны, но нужно и понимать их практическую пользу.
Что касается реально сложных запросов и тем более динамической сборки запросов, то здесь для любителей прямого SQL всё гораздо хуже. LINQ позволяет на порядок проще строить на порядок более оптимальные запросы. На практике для генерации прямого SQL народ либо строит универсальные view, в который вбиты все возможные джоины, либо тупо упирается в сложность, и как результат, в глючность решения. Тогда как при использовании ассоциаций LINQ автоматически строит все нужные джоины, устраняет вещи типа "@p = NULL OR Field1 = @p" и т.п.
Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень. Это можно сравнить разве что с переходм от C/C++ модели памяти (предлагаю не начинать обсуждать возможные костыли вроде auto_ptr, я в курсе), где хождение по граблям занимает большую часть времеи, к автоматической сборке, где высвобожденное время можно с успехом потратить, например, на архитектуру приложения и добиться лучшей производительности архитектурными решениями. А это уже может оказаться не 2%, а 2000.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень.
Это преимущество достижимо и без runtime overhead.
IT>где высвобожденное время можно с успехом потратить, например, на архитектуру приложения и добиться лучшей производительности архитектурными решениями. А это уже может оказаться не 2%, а 2000.
Ага, вот прям высвобожденное время бегут тратить на архитектуру: для простейшего алгоритма в десяток строк в итоге нагенерили 4k строк — точно 2000%
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это преимущество достижимо и без runtime overhead.
Это мы уже обсуждали прямо тут. Оказалось, что во-первых, не особенно достижимо, а во-вторых, не особенно overhead.
EP>Ага, вот прям высвобожденное время бегут тратить на архитектуру: для простейшего алгоритма в десяток строк в итоге нагенерили 4k строк — точно 2000%
В огороде бузина, а в Киеве дядька. Знаешь такую пословицу? Это про тебя. Какое отношение имеет приведённый код к обсуждаемой теме? Ах да, общее всё же есть — желание покидаться какашками. Тут такое дело, заляпаешь ты оппонента или нет это ещё вопрос, но у самого ручки в говне будут точно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
EP>>Это преимущество достижимо и без runtime overhead. IT>Это мы уже обсуждали прямо тут. Оказалось, что во-первых, не особенно достижимо,
Почему не особенно? Вполне достижимо.
EP>>Ага, вот прям высвобожденное время бегут тратить на архитектуру: для простейшего алгоритма в десяток строк в итоге нагенерили 4k строк — точно 2000% IT>В огороде бузина, а в Киеве дядька. Знаешь такую пословицу? Это про тебя. Какое отношение имеет приведённый код к обсуждаемой теме? Ах да, общее всё же есть — желание покидаться какашками. Тут такое дело, заляпаешь ты оппонента или нет это ещё вопрос, но у самого ручки в говне будут точно.
Это ответ на твою желтизну про высвобожденное время и 2000%, которая была совершенно не в тему
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>В огороде бузина, а в Киеве дядька. Знаешь такую пословицу? Это про тебя. Какое отношение имеет приведённый код к обсуждаемой теме? Ах да, общее всё же есть — желание покидаться какашками. Тут такое дело, заляпаешь ты оппонента или нет это ещё вопрос, но у самого ручки в говне будут точно.
EP>Это ответ на твою желтизну про высвобожденное время и 2000%, которая была совершенно не в тему
Раскрой глаза — высвобожденное время и новая архитектура это тренд последних 20 или 30 лет. А именно — менеджед решения, гибриды всех сортов и позволяют ввести абсолютно новую архитектуру, где от плюсов требуется только числодробилки.
Для того, что бы World Of Tanks могли ставить рекорды, часть кода надо писать вместо плюсов на питоне, иначе это никогда не взлетит.
HTML, CSS, JS — это еще один пример. Для того, что бы браузер поддерживал конское количество фич и адскую производительность, надо разделить ядро на две части — менеджед и нативную, в противном случае шансов у тебя нет.
Ровно тем же путем идет любая серьезная плюсовая рисовалка — сначала появляются DSL стилей, потом выделяется кастомная логика, и все это дает возможность, внимание, оптимизировать само плюсовое ядро.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>Это мы уже обсуждали прямо тут. Оказалось, что во-первых, не особенно достижимо, EP>Почему не особенно? Вполне достижимо.
Да уже сто раз обсуждали. Поставить в один ряд обычный код и работу с базой данных может только LINQ, благодаря полной типизации и поддержке компилятора. Когда я говорю в один ряд, то имею ввиду применимость к работе с БД таких средств как ReSharper, 100% проверка кода компилятором C# и прочие из этого вытекающие прелести. Всё остальное — костыли, которые пытаются к этому приблизиться. Это можно сделать лучше только, если компилятор будет поддерживать встроенные DSL, тогда можно было бы сделать ещё лучше. Но, к сожалению, Немерле не выстрелил, а только немножко пукнул, и то не громко, а полноценная макросистема в Рослине появится не ранее, чем версий через несколько. Если вообще появится.
EP>Это ответ на твою желтизну про высвобожденное время и 2000%, которая была совершенно не в тему
На мою желтизну не стоило пинать совершенно не причастную к теме библиотеку.
Кстати, код который ты привёл полностью сгенерированный, т.е. требует минимальной поддержки. Универсальный метод, о котором ты говоришь там тоже есть и он рукописный, в дргом файле. Зачем это всё надо? Ну, лично мне побарабану на 2%-5%, но народу захотелось. Сделать не сложно, поддержка, как я уже сказал, минимальная. Пусть будет. Если бы я все проблемы с прямым SQL решал с такой же лёгкостью, то я бы никогда не перешёл на LINQ.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Это мы уже обсуждали прямо тут. Оказалось, что во-первых, не особенно достижимо, EP>>Почему не особенно? Вполне достижимо. IT>Да уже сто раз обсуждали. Поставить в один ряд обычный код и работу с базой данных может только LINQ, благодаря полной типизации и поддержке компилятора.
Не только LINQ.
IT>Когда я говорю в один ряд, то имею ввиду применимость к работе с БД таких средств как ReSharper, 100% проверка кода компилятором C# и прочие из этого вытекающие прелести.
Для этого runtime overhead не обязателен.
IT>Всё остальное — костыли, которые пытаются к этому приблизиться. Это можно сделать лучше только, если компилятор будет поддерживать встроенные DSL, тогда можно было бы сделать ещё лучше.
То есть ты таки согласен с моим исходным утверждением, что type safety при работе с БД можно достичь и без runtime overhead'а LINQ'а?
Тогда с чем споришь?
С тем что для некоторых задач этот overhead не критичен? Так с этим и я не спорю.
IT>Но, к сожалению, Немерле не выстрелил, а только немножко пукнул, и то не громко, а полноценная макросистема в Рослине появится не ранее, чем версий через несколько. Если вообще появится.
Не суть важно, подобное (compile-time DSL для запросов к БД) реализуемо уже сегодня и в Nemerle, и в D, и даже в C++.
EP>>Это ответ на твою желтизну про высвобожденное время и 2000%, которая была совершенно не в тему IT>На мою желтизну не стоило пинать совершенно не причастную к теме библиотеку.
Не стоило вообще изначально делать демагого-маркетинговые-2000% заявления, начал ведь хорошо.
IT>Кстати, код который ты привёл полностью сгенерированный,
О чём я сразу же и сказал
IT>т.е. требует минимальной поддержки.
Генерируемый код через склейку текста требует большей поддержки нежели аналогичный обычный код выраженный средствами языка — его труднее писать, труднее отлаживать, труднее править и т.д. и т.п.
IT>Универсальный метод, о котором ты говоришь там тоже есть и он рукописный, в дргом файле.
Нет, я говорю конкретно про вот эту генерацию. Которая, будь язык/компилятор мощнее, и не понадобилась бы вовсе — так как это выражалось бы непосредственно в коде/языке, а не через текстовые шаблонизаторы. А ведь могли бы время на архитектуру потратить и получить 2000%!
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>Да уже сто раз обсуждали. Поставить в один ряд обычный код и работу с базой данных может только LINQ, благодаря полной типизации и поддержке компилятора. EP>Не только LINQ.
Если ты что-то знаешь, то не держи в себе. Поделись с друзьями и тебе сразу станет легче А то всё какие-то намёки...
IT>>Когда я говорю в один ряд, то имею ввиду применимость к работе с БД таких средств как ReSharper, 100% проверка кода компилятором C# и прочие из этого вытекающие прелести. EP>Для этого runtime overhead не обязателен.
Пока ты не раскрыл своей тайны я не знаю как без него.
EP>То есть ты таки согласен с моим исходным утверждением, что type safety при работе с БД можно достичь и без runtime overhead'а LINQ'а?
Если в языке есть мощная поддержка разработки DSL, то для запросов не требующих динамики и точно знающих с каким сервером они работают, конечно, можно.
EP>Тогда с чем споришь?
С тем что пока этого нигде нет.
EP>С тем что для некоторых задач этот overhead не критичен? Так с этим и я не спорю.
Для некоторых — это примерно 99%.
EP>Не суть важно, подобное (compile-time DSL для запросов к БД) реализуемо уже сегодня и в Nemerle, и в D, и даже в C++.
В Немерле реализован не DSL, а демонстрация возможностей макросистемы. В жизни их поддержка SQL мало применима, но как демка для макросов очень хороша. C++ мы как раз разбираем в этой теме. Потуги есть, но результат от идеала так же далёк как и плюсовая система макропрограммирования, основанныя на побочных эффектах компилятора. Про D не знаю, но что-то ничего не слышал о том, чтобы он полноценно поддерживал разработку DSL.
EP>Не стоило вообще изначально делать демагого-маркетинговые-2000% заявления, начал ведь хорошо.
Так тебя сама цифра смущает? Ну так спиши нолик. Так лучше?
IT>>т.е. требует минимальной поддержки. EP>Генерируемый код через склейку текста требует большей поддержки нежели аналогичный обычный код выраженный средствами языка — его труднее писать, труднее отлаживать, труднее править и т.д. и т.п.
Генерируемый код вообще не требует никакой поддержки. Поддержки требует код генератора. В данном случае код генератора прост как угол дома. Вообще-то, precompile time генерация кода самый простой и на сегодняшний день доступный вид метапрограммирования. Так что твои жалобы на сложность поддержки такого решения я не разделяю.
EP>Нет, я говорю конкретно про вот эту генерацию. Которая, будь язык/компилятор мощнее, и не понадобилась бы вовсе — так как это выражалось бы непосредственно в коде/языке, а не через текстовые шаблонизаторы.
Её не могло бы не понадобиться. Код генерации всё равно пришлось бы написать. Какое из решений лучше: pre-compile time или compile time генерация кода сказать без наличия последней сложно. Эту задачу шаблоны решают на раз два, я за вечер несколько штук таких наклепал. А вот с макросами точно провозился бы дольше.
EP>А ведь могли бы время на архитектуру потратить и получить 2000%!
Твой сарказм не уместен.
Кстати. 2000 — это же у нас всего лишь в 20 раз, правильно? Ну тогда это не самый выдающийся результат. За счёт архитектуры приходилось вытягивать производительность и в большее количество раз. Но это уже правда на совсем убитых проектах.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>>>Да уже сто раз обсуждали. Поставить в один ряд обычный код и работу с базой данных может только LINQ, благодаря полной типизации и поддержке компилятора. EP>>Не только LINQ. IT>Если ты что-то знаешь, то не держи в себе. Поделись с друзьями и тебе сразу станет легче А то всё какие-то намёки...
Например ODB, sqlpp11.
IT>>>Когда я говорю в один ряд, то имею ввиду применимость к работе с БД таких средств как ReSharper, 100% проверка кода компилятором C# и прочие из этого вытекающие прелести. EP>>Для этого runtime overhead не обязателен. IT>Пока ты не раскрыл своей тайны я не знаю как без него.
А в чём принципиальная проблема сгенерировать из type-safe DSL необходимый код до runtime?
EP>>То есть ты таки согласен с моим исходным утверждением, что type safety при работе с БД можно достичь и без runtime overhead'а LINQ'а? IT>Если в языке есть мощная поддержка разработки DSL,
Для данного тезиса не важно — есть ли поддержка создания новых DSL, либо этот DSL запросов жёстко зашит.
Я о том что такой DSL принципиально возможен.
А твоя фраза:
IT>Ну и под конец главный козырь LINQ — type safety. Можете мне петь любые песни про любые тормоза, но это преимущество ни много ни мало переводит работу с БД на принципиально другой уровень.
Звучит так, как будто overhead LINQ'а является необходимым для type safety которую он даёт — вот с этим я и не согласен.
IT>то для запросов не требующих динамики и точно знающих с каким сервером они работают, конечно, можно.
Для динамики производящей ограниченное число вариантов (скажем 128) — можно статически сгененрировать все варианты результатов.
Даже без генерации всех вариантов заранее, приличную часть работы можно сделать в compile-time.
IT>плюсовая система макропрограммирования, основанныя на побочных эффектах компилятора
Побочный эффект компилятора это например печать ряда простых чисел через error messages.
А то что сейчас в C++ называется метапрограммированием по большей части основано на побочном эффекте от наличия мощной системы типов.
IT>Про D не знаю, но что-то ничего не слышал о том, чтобы он полноценно поддерживал разработку DSL.
В нём как минимум есть compile-time работа со строками, в которые можно запихнуть какой угодно DSL.
EP>>Не стоило вообще изначально делать демагого-маркетинговые-2000% заявления, начал ведь хорошо. IT>Так тебя сама цифра смущает? Ну так спиши нолик. Так лучше?
Цифра вторична. Само высказывание мол ну и что что язык/платформа/технология/etc/etc тормозные, зато мы вас переархитектурим — чересчур демагогично. Типа сказал и сразу в домике, удобно чо — ведь и не опровергнешь Но интересней же обсуждать технические аргументы, а не сфероконей.
IT>>>т.е. требует минимальной поддержки. EP>>Генерируемый код через склейку текста требует большей поддержки нежели аналогичный обычный код выраженный средствами языка — его труднее писать, труднее отлаживать, труднее править и т.д. и т.п. IT>Генерируемый код вообще не требует никакой поддержки. Поддержки требует код генератора.
Большей нежели обычный код.
IT>Вообще-то, precompile time генерация кода самый простой и на сегодняшний день доступный вид метапрограммирования.
В своих проектах я это использую в том числе.
Но сейчас говорю о том, что в этом месте вообще не нужно никакое метапрограммирование, был бы язык/компилятор чуточку мощнее
IT>Так что твои жалобы на сложность поддержки такого решения я не разделяю.
Я не жалуюсь, я не говорю что слишком сложно или невозможно, я утверждаю что его поддерживать сложнее чем обычный код. Вполне очевидный факт жеж.
EP>>Нет, я говорю конкретно про вот эту генерацию. Которая, будь язык/компилятор мощнее, и не понадобилась бы вовсе — так как это выражалось бы непосредственно в коде/языке, а не через текстовые шаблонизаторы. IT>Её не могло бы не понадобиться. Код генерации всё равно пришлось бы написать.
Почему?
IT>Какое из решений лучше: pre-compile time или compile time генерация кода сказать без наличия последней сложно. Эту задачу шаблоны решают на раз два, я за вечер несколько штук таких наклепал. А вот с макросами точно провозился бы дольше.
В C++ эта задача решается обычными шаблонами, причём это совсем не то что называется метапрограммированием, а является обычным обобщением.
EP>>А ведь могли бы время на архитектуру потратить и получить 2000%! IT>Твой сарказм не уместен.
Почему? Если ты считаешь что на работу с памятью уходит аж столько времени, что в управляемых языках архитектуря всё это время не только догоняют, но и перегоняют на порядки, то почему нельзя считать что время потраченное на борьбу с ущербностью языка/платформы при реализации простейшего алгоритма не могло быть потрачено на ту же самую передовую и быструю архитектуру?
IT>Кстати. 2000 — это же у нас всего лишь в 20 раз, правильно? Ну тогда это не самый выдающийся результат. За счёт архитектуры приходилось вытягивать производительность и в большее количество раз. Но это уже правда на совсем убитых проектах.
А я не спорю с тем что хорошими инженерными решениями можно увеличить скорость на порядки, или точно также как и плохими замедлить на те же порядки, это в общем-то очевидно. Не говоря уже об разнице в алгоритмической сложности.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
IT>>Если ты что-то знаешь, то не держи в себе. Поделись с друзьями и тебе сразу станет легче А то всё какие-то намёки...
EP>Например ODB, sqlpp11.
Так повтори тесты на ODB, делов то. sqlpp11, как выяснилось, ничего внятного не умеет и это не ORM. Так утверждает его автор.
ODB — ORM. Судя по интернету, никто даже не пробовал внятно замеры делать. Первая страница ссылок ведет на блог товарища, кторый сравнивает C# с неизвестнм железом против ODB с конкретным, при чем совсем другой БД. Прямо как alex_public — "Cмотрите, sqlite работает на с++ за 12микросекунд !!!!!!11111"
LINQ2DB имхо круче всех и тесты это подтверждают :).
Разница с ADO.NET настолько минимальна, что ею можно пренебречь. Разница заметна только на крайне простых запросах ("Simple TOP 10 query"), где абсолютное время настолько мало, что им имхо можно пренебречь.
На хоть сколько-нибудь более сложных запросах ("Simple TOP 500 query" или тем более "Complex TOP 10 query", хотя и он по факту не сильно сложный) накладные расходы и вовсе находятся в районе погрешности измерения. Зато при этом мы имеем LINQ со статической типизацией.
Здравствуйте, alex_public, Вы писали: _>Ну так если ты настаиваешь, что 5% — это самый большой возможный уровень накладных расходов у linq2db, то как ты тогда объясняешь 90% в данном http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html тесте (случай Simple TOP 10 query)?
Про 90% своё имхо написал выше. Думаю в реальных запросах эти расходы будут значительно меньше 5% (в 99% случаев).
Здравствуйте, IT, Вы писали: IT>Это объясняется тем, что я вообще не понимаю что тестируют эти тесты.
Тесты тестируют скорость выволнения запросов :). На время инициализации контекста можно не смотреть, т.к. что имеено в него входит я не знаю — можно смотреть только суммарное время выпонения запроса. Контекстом я хотел померять накладные расходы за вычетом самого запроса (компилция LINQ, выполнение запроса, материализация). И как видно по тестам, на что-то там ещё тратится время, хоть и незначительное.
IT>LINQ: 100000 in 00:00:05.7321425 IT>ADO: 100000 in 00:00:05.5328326 IT>Разница в районе одного процента туда суда. А если я ещё добавлю в тест ADO.NET проверку на DBNull, то он вообще может оказаться медленнее.
Так и есть, разницы практически нет, а начиная с "Simple TOP 500 query" LINQ2DB каким-то образом выигрывает у ADO.NET :).
Здравствуйте, gandjustas, Вы писали: G>По ссылке время замеряется вместе с инициализацией контекста\открытием соединения, а у тебя — только время запросов. G>Тесты проверял, у меня порядок цифр такой же.
В действительности время соединения тут не замеряется нигде, т.к. в ADO.NET используется Connection Pooling ( https://msdn.microsoft.com/en-us/library/8xx3tyca(v=vs.110).aspx )
Здравствуйте, IT, Вы писали: IT>Если внести открытие соединения в замер, то получится ~2%. Но никак не 90%. К тому же открытие соединения измерять не совсем верно, т.к. множество запросов на одном соединении — обычное дело.
На открытие соединения по вышеприведённой причине тратится 0% времени, и измерять его не вижу смысла, т.к. оно не зависит от наличия LINQ'а и используемой ORM. Я хотел протестировать именно ORM.
IT>Здравствуйте, Sinclair, Вы писали: S>>Они выполняют один реквест в соединении, потом два реквеста, и решают систему линейных уравнений t1=t0+tR, t2=t0+2*tR IT>Один или два реквеста в тестах — это точность примерно на уровне статистической погрешности. Чтобы более менее что-то измерить нужны тысячи итераций, а лучше миллионы.
Примерно так и есть, используется 100 итераций для разогрева и 1000 для замера. Делать больше не знаю есть ли смысл, т.к. ждать надо будет сильно дольше, а результаты немного прыгают между замерами (без влияния на результаты тестирования).
Здравствуйте, IT, Вы писали: IT>Во-вторых, в реальности на ADO.NET так никто не пишет. Ни один вменяемый разработчик не будет использовать индексы вместо имён полей. Такой код живёт ровно до первого изменения.
В реальности не только так, а вообще на ADO.NET нет особого смысла писать :). Индексами я хотел выжать максимум из ADO.NET без усложнения кода, чтобы сравнить его самую быструю работу с другими ORM.
Если нам не помогут, то мы тоже никого не пощадим.
А то всё какие-то намёки...
Ну так спиши нолик. Так лучше? 
