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

I>Я невнимательно прочел код, у тебя в замеры в одном месте попадает tr.commit

Транзакция там в одном месте исключительно для ускорения множественной вставки (стандартный приём). И опять же это всё никак не влияет на цифры накладных расходов библиотеки. Потому что мы можем измерять в данном тесте вообще всё что угодно. Главное чтобы это было одно и тоже в двух запускаемых исходниках. И соответственно вычисляя далее разницу между ними мы получаем накладные расходы. Т.е. говорить о некорректности подобного теста ты мог бы ровно в одном случае — если бы обнаружил что в этих двух исходниках измеряются не совсем одинаковые вещи.

I>Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.

Всё верно, на миллисекундных запросах (вполне стандартное значение для реальных БД) данная библиотечка можно сказать не привносит никаких накладных расходов. В отличие от всех решений на базе linq, в которых на подобных запросах накладные расходы вполне себе ощущаются. И только при замерах на нереальных микросекундных запросах появляются какие-то накладные расходы и у такой библиотечки.

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

>>разница явно где-то за пределами погрешности измерения. И только введение индекса (и соответственно приведение времени запроса к смешным значениям) позволило выявить реальный размер накладных расходов данной библиотечки
I>В кратце, это признание того, что на фоне обращения к базе твою оптимизацию в микроскоп не видно.
I>В реальной работе такого фокуса у тебя не будет, потому что уже сеть съест весь профит. Еще раз — ты перепахиваешь виртуальную память !

Всё верно. ) Я согласен, что нет смысла делать оптимизацию вида перехода от sqlpp к голым строкам. Про которую ты сейчас и написал. Потому что микросекундные запросы в реальности не встречаются. А вот миллисекундные очень даже...

_>>P.S. Ну и для общего образования: обращение к памяти — это наносекунды, у нас всё же не 90-ые. )))
I>Ты всё таки не можешь удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io

Там где commit и запись на диске — там вообще десятки миллисекунд. А микросекунды (вместо наносекунд) в запросах с индексом к памяти получаются как раз потому, что это sql (а не отображаемый в память файл с фиксированной структурой), который при обработке запроса делает ещё много чего, помимо собственно доступа к данным.

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

_>>Никто про "всё лучше делать вручную" не говорил. Речь шла про конкретный пример из данной статьи http://blog.gandjustas.ru/2014/09/23/asp.net-linq-ef-sql-server-performance/, про который я высказал оценку, что он бредовый, т.к. сравнивает исключительно хранимку vs linq.
N>Тогда ты очень плохо держишь исходную тему в процессе обсуждения. Потому что уже после 2-3 последующих сообщений этот исходный пример ушёл куда-то погулять, а вы радостно переключились на сложности формирования SQL.

Ну т.к. моим самым изначальным тезисом (с которого и началось всё это длинное обсуждение) было что-то вроде "все ORM на базе Linq тормознутые", то данные отклонения от темы тоже вполне попадали в рамки.

N>Пример как раз достаточно разумный, если исходить из практики. Хранимка тут как раз малосущественна, такой же запрос с case внутри (неважно, явном или нет) можно было послать и напрямую с клиента (да, я видел такое в реальности). Различие именно в том, чьи затраты меньше — локального генератора (linq2db или аналога) или сервера (сможет ли сервер, например, сразу сэкономить на входе на ветке, которая при компиляции SQL запроса для него константа false).

Ты похоже вообще не прочитал его статью. ))) Как раз дело в том, что сервер компилирует хранимку/запрос один раз при первом использование и дальше использует готовое. Причём проводит оптимизацию. Так вот в данном случае будет получаться оптимизированное решение под одно значение параметра, которое будет сильно тормозить при другом значение параметра. Что бы сделать в данном случае оптимизированное решение на хранимках достаточно было бы просто написать две отдельных хранимки (для null и для нормального значения) и вызывать нужную в конкретном случае. Но это как раз уже выглядит длиннее и неудобнее. В отличие от случая с запросом в коде, где создание вариативного запроса записывается проще и короче чем один сложный универсальный (и при этом медленный из-за вышеописанных причин) запрос.

N>Но дальше вы тут же растеклись на что-то совсем странное. Ты вот утверждаешь, что там внутри сплошная рефлексия, а коллеги — что там expression trees. Мне тут больше непонятно, почему рефлексия такая чудовищно дорогая — миллисекунды. Но если её нет, то и дороговизны нет, а ты ничего не мерял.

http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html всё вполне себе измерено. Правда не мной, но так даже лучше (никто не будет придираться к пристрастности тестера ).

_>> Потому как самая короткая запись обычного запроса является одновременно и самой оптимизированной.
N>Запроса SQL? Тогда это в общем случае, мягко говоря, сомнительно. И есть контрпримеры для многих баз, когда вложенный select дешевле сложного join, и другие аналогичные тонкости.

Речь про конкретный пример из статьи, а не про вообще.

_>> Но меня трудно назвать сторонником данного подхода, т.к. я собственно не сторонник самого C#. )))
N>Ну, зачем ты перешёл на рекламу C++ в треде дотнет против явы, отдельный вопрос.

А вот как раз этого и не было. Я в этой теме изначально писал только о тормозах Linq ORM и всё. Это оппоненты начали припоминать старые дискуссии и тащить сюда примеры из C++ (в стиле ну и пусть Linq тормозит слегка, но зато он может такое, чего твои C++ решения никогда не смогут).

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

_>>Откуда экспоненциально? ) Как раз чётко линейно по количеству фильтров и таблиц.
·>Сложность условия if зависит от того в что как пересекается.
·>В оригинальном коде — три тривиальных if (с одним условием), притом они могут стоять в любом порядке — достаточно написать три whitebox теста. В твоём коде с комбинациями условий, да в строго определённом порядке — хз... для безопасности я бы написал все восемь (2³).

И откуда ты взял бред про строго определённый порядок? )

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

_>>Такие фразы надо прямо записывать. Хорошо, сформулирую по другому, для особо одарённых. ) Подскажи мне какая ORM основанная на Linq обходится без рефлексии? )
·>Обсуждаемые нами linq2sql и вроде linq2db

https://github.com/linq2db/linq2db/tree/master/Source/Reflection ага, ага. )))

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

IT>Опять же. Я не вижу здесь вообще повода для дискуссии. Сделать оптимизации для конкретного сервера и разный код для разных СУБД — это задачи одного порядка. Там где нужно всё это делается.

Хы, ну просто если считать и такие синтаксические вещи, предоставляемые провайдером, за оптимизацию, то тогда можно сказать, что и во всех библиотечках абстрагирующих запрос в СУБД от вида конкретной СУБД есть умные оптимизации. )))

_>>Что-то сомнительно, сам же писал выше какие там проблемы возникают. ) Вот в предкомпилированные запросы я ещё верю, правда они не везде применимы и не так удобны.
IT>Это не вопрос веры. Не надо верить / не верить. Можно всять и протестировать. Или хотя бы посмотреть результаты существующих тестов.

Ну вот тесты как раз показывают, что появляются вполне себе ощутимые накладные расходы.

IT>Тем более, что в плохом провайдере подготовка запроса это не всегда основные тормоза. Как правило тесты делаются на нешироких таблицах, в 3-4 целочисленных поля. Если же зарядить запрос на таблицу с 50-ю полями и вытащить из неё записей тыщ двадцать, то вполне может оказаться, что материализация этих данных в объекты и есть главные тормоза.

Безусловно. И тесты опять же подтверждают твои слова. Только вот как раз чаще бывают запросы на небольшое число строк в результате (т.к. пользователю редко нужно лицезреть сразу тысячи строк). Более того, одним из самых популярных в веб'е запросов всегда был запрос на данные пользователя по идентифицирующей его сессии, который исполняется практически мгновенно (запрос на индекс с единственной строкой в результате).

P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?

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

_>>Имеем где-то порядка 2-12 микросекунд накладных расходов на простом запросе классического вида ради получения статически типизированного кода.
IT>Что-то я не увидел тут статически типизированного кода. Голимые SQL строки.

Там два исходника. ) В одном как раз голые sql строки, чтобы было относительно чего рассчитывать накладные расходы. А вот во втором уже вообще ни одной строчки текстом нет.

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

_>Там два исходника. ) В одном как раз голые sql строки, чтобы было относительно чего рассчитывать накладные расходы. А вот во втором уже вообще ни одной строчки текстом нет.

Точно. Второй сразу не заметил. Так это у тебя что-то вроде сборки SQL AST?

Кстати, что будет сгенерировано, если parameter(test.fvalue) окажется null?

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

_>Хы, ну просто если считать и такие синтаксические вещи, предоставляемые провайдером, за оптимизацию, то тогда можно сказать, что и во всех библиотечках абстрагирующих запрос в СУБД от вида конкретной СУБД есть умные оптимизации. )))

Ты бы тогда дал определение оптимизации под конкретную СУБД. OUTER APPLY это тоже не оно? Ты почему-то решил опустить эту часть, что не совсем понятно.

_>Ну вот тесты как раз показывают, что появляются вполне себе ощутимые накладные расходы.

Какие именно тесты?

_>Безусловно. И тесты опять же подтверждают твои слова. Только вот как раз чаще бывают запросы на небольшое число строк в результате (т.к. пользователю редко нужно лицезреть сразу тысячи строк).

Чаще бывают у кого?

_>Более того, одним из самых популярных в веб'е запросов всегда был запрос на данные пользователя по идентифицирующей его сессии, который исполняется практически мгновенно (запрос на индекс с единственной строкой в результате).

Есть такое дело. На этом сайте в том числе. И как-то оно работает себе и работает.

Это всё не проблема. Вообще ни разу. Моя последняя возня с оптимизацией запросов вообще не имеет никакого отношения к linq. В основном это изучение плана запросов, создание индексов, партиционирование и т.п. С linq возникают только проблемы поддержки конкретной базы. Например, на C# нельзя выразить рекурсивный CTE. Пичалька TABLE и QUERY hints сделали, а до JOIN hint всё руки никак не дойдут.

Вот где проблемы. А производительность вполне устраивает и даже более чем. К тому же, например, в том числе и на этом сайте переписывание некоторых запросов с сохранённых процедур и прямого SQL позволило существенно увеличить производительность. Правда странно? А всё дело в выразительности используемых средств. Там где SQL девелопер родит один запрос, я на linq напишу его 5 раз и попробую разные варианты. Там где SQL девелопер напишет что-то типа WHERE @p IS NULL OR Field1 = @p, чтобы не заниматься склейкой строк, я поставлю if в коде и получу гораздо более оптимальный SQL. И т.п.

К тому же linq2db вообще не ограничивает девелопера никаким образом. Считаешь, что данный конкретный запрос лучше написать ручками — хоть оппишись. Сам себе злобный буратина. Таких запросов как ты упомянул обычно 1-2 на всё приложение. Напиши их на SQL, если даже CompiledQuery не устраивает.

_>P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?

А такое возможно в принципе?

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

_>>Там два исходника. ) В одном как раз голые sql строки, чтобы было относительно чего рассчитывать накладные расходы. А вот во втором уже вообще ни одной строчки текстом нет.
IT>Точно. Второй сразу не заметил. Так это у тебя что-то вроде сборки SQL AST?

Да, типа того, только большая часть работы происходит на этапе компиляции (метапрограммирование на шаблонах C++). ) Ну и я не автор этой библиотечки, а просто протестировал её для примера.

IT>Кстати, что будет сгенерировано, если parameter(test.fvalue) окажется null?

А как float (да и любой другой тип в C++) по твоему может быть null? )))

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

_>>Хы, ну просто если считать и такие синтаксические вещи, предоставляемые провайдером, за оптимизацию, то тогда можно сказать, что и во всех библиотечках абстрагирующих запрос в СУБД от вида конкретной СУБД есть умные оптимизации. )))
IT>Ты бы тогда дал определение оптимизации под конкретную СУБД. OUTER APPLY это тоже не оно? Ты почему-то решил опустить эту часть, что не совсем понятно.

Я просто с SQL Server дел не имею, так что не особо в курсе что это там такое. Сейчас глянул — это вроде тоже самое, что в других СУБД называют JOIN LATERAL? ) В таком случае мне кажется что подобное должно задаваться всё же самим программистом...

_>>Ну вот тесты как раз показывают, что появляются вполне себе ощутимые накладные расходы.
IT>Какие именно тесты?

Например вот эти http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html, тебе же их вроде уже показывали тут.

_>>Более того, одним из самых популярных в веб'е запросов всегда был запрос на данные пользователя по идентифицирующей его сессии, который исполняется практически мгновенно (запрос на индекс с единственной строкой в результате).
IT>Есть такое дело. На этом сайте в том числе. И как-то оно работает себе и работает.

Ну так это у нас и не высоконагруженный сайт. )))

IT>Вот где проблемы. А производительность вполне устраивает и даже более чем. К тому же, например, в том числе и на этом сайте переписывание некоторых запросов с сохранённых процедур и прямого SQL позволило существенно увеличить производительность. Правда странно? А всё дело в выразительности используемых средств. Там где SQL девелопер родит один запрос, я на linq напишу его 5 раз и попробую разные варианты. Там где SQL девелопер напишет что-то типа WHERE @p IS NULL OR Field1 = @p, чтобы не заниматься склейкой строк, я поставлю if в коде и получу гораздо более оптимальный SQL. И т.п.

Почему странно? Нормально) Я тут и про хранимки писал что ни к чему они. )

IT>К тому же linq2db вообще не ограничивает девелопера никаким образом. Считаешь, что данный конкретный запрос лучше написать ручками — хоть оппишись. Сам себе злобный буратина. Таких запросов как ты упомянул обычно 1-2 на всё приложение. Напиши их на SQL, если даже CompiledQuery не устраивает.

Так к linq2db в режиме sql строк вообще никаких вопросов нет. )))

_>>P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?
IT>А такое возможно в принципе?

Нуу большинство СУБД же поддерживают такое. Даже простенький sqlite может. Собственно в тех двух исходниках теста для sqlite были примеры как одного подхода, так и второго. Или мы о разных вещах говорим? )

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

_>Да, типа того, только большая часть работы происходит на этапе компиляции (метапрограммирование на шаблонах C++). ) Ну и я не автор этой библиотечки, а просто протестировал её для примера.

Понятно. Такие решения мы тоже проходили в своё время и определили их в малопригодные для реальной жизни.

IT>>Кстати, что будет сгенерировано, если parameter(test.fvalue) окажется null?
_>А как float (да и любой другой тип в C++) по твоему может быть null? )))

Действительно. Т.е. либо потом косяки отлавливать, либо упоротый монструозный код писать.

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

IT>>Ты бы тогда дал определение оптимизации под конкретную СУБД. OUTER APPLY это тоже не оно? Ты почему-то решил опустить эту часть, что не совсем понятно.
_>Я просто с SQL Server дел не имею, так что не особо в курсе что это там такое. Сейчас глянул — это вроде тоже самое, что в других СУБД называют JOIN LATERAL? )

В других это в PostreSQL? Кстати, раньше такого у них не видел. Когда они это добавили? Нужно в linq2db добавить поддержку.

_>В таком случае мне кажется что подобное должно задаваться всё же самим программистом...

Зачем?

_>Например вот эти http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html, тебе же их вроде уже показывали тут.

Показывали, потому и не пойму о чём речь. Там вроде ощутимость только у EF. Также там нет тестов CompiledQuery.

_>Ну так это у нас и не высоконагруженный сайт. )))

Да без разницы. Конкретно эта проблема решается не бысрым доступом к БД, а кешированием.

_>>>P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?
IT>>А такое возможно в принципе?
_>Нуу большинство СУБД же поддерживают такое. Даже простенький sqlite может. Собственно в тех двух исходниках теста для sqlite были примеры как одного подхода, так и второго. Или мы о разных вещах говорим? )

Видимо мы о чём-то разном. Предкомриляция запроса внутри БД делается самой БД без каких-либо телодвижений с клиента. Если ты о методе Prepare из ADO.NET, то он делается на открытом соединении и держать его открытым между вызовами не самая лучшая идея.

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

I>>Ты перепахиваешь память и только по этому у тебя заметны издержки. Как только начинаешь работать уже с диском, то разницы, по твоим же словам, не видно никакой.

_>Всё верно, на миллисекундных запросах (вполне стандартное значение для реальных БД) данная библиотечка можно сказать не привносит никаких накладных расходов. В отличие от всех решений на базе linq, в которых на подобных запросах накладные расходы вполне себе ощущаются. И только при замерах на нереальных микросекундных запросах появляются какие-то накладные расходы и у такой библиотечки.

У таких библиотек основной профит, вообще говоря, производительность БД. Если linq готовит запрос, что бы ничего лишнего не ушло в базу и не пришло из базы, то очень странно сравнивать с твоей поделкой, которая ничего этого не делает.

I>>Ты всё таки не можешь удержаться, что бы не юродствовать. Типа ты не понял, что речь про _виртуальную_ _память_ и надо считать commit и дисковый io

_>Там где commit и запись на диске — там вообще десятки миллисекунд.

То есть, о чем речь — ты хорошо понял, про какие числа идёт речь, только про привычке продолжил юродствовать

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

>>>Такие фразы надо прямо записывать. Хорошо, сформулирую по другому, для особо одарённых. ) Подскажи мне какая ORM основанная на Linq обходится без рефлексии? )
_>·>Обсуждаемые нами linq2sql и вроде linq2db

_>https://github.com/linq2db/linq2db/tree/master/Source/Reflection ага, ага. )))

Ты утверждал, что именно рефлексия есть основной источник потери производительность. И вот выясняется, что никак показать это не можешь.

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

_>P.S. О, кстати, давно хотел спросить у кого-нибудь разбирающегося (а то лень смотреть по документациям). Предкомпилированные запросы в linq2db, EF и т.п. библиотеках включают в себя только предкомпиляцию sql строки или же включают в себе и предкомпиляцию запроса внутри СУБД?

Все серьезные БД нынче кешируют результаты компиляции запроса унутре. linq работает совсем в другом слое и эти чудеса никак не контролирует.

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

_>А вот как раз этого и не было. Я в этой теме изначально писал только о тормозах Linq ORM и всё. Это оппоненты начали припоминать старые дискуссии и тащить сюда примеры из C++ (в стиле ну и пусть Linq тормозит слегка, но зато он может такое, чего твои C++ решения никогда не смогут).

Все ходы записаны. Ты сначала сказал что линк невозможно тормозит и в качестве причины "строить sql строки в рантайме на базе тормознутой рефлексии".
То есть, здесь уже замер не относительно узкого места что обычно БД или сеть, а относительно некоего эталона.
Тебе показали, что именно linq делает с запросом. Ты этот же фокус не смог продемонстрировать своей поделкой.

И кстати говоря, высказывание про построение строк на базе рефлексии так и осталось недоказаным.

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

_>А как float (да и любой другой тип в C++) по твоему может быть null? )))

А в базе данных — может. Пудозреваю, IT говорит о разнице в SQL. a = b и a is NULL

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

IT>Например, на C# нельзя выразить рекурсивный CTE. Пичалька TABLE и QUERY hints сделали, а до JOIN hint всё руки никак не дойдут.

А как на C# можно написать TABLE и QUERY hints?

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

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

_>>>Изначальный мой тезис (с которого началась вся эта бесконечная дискуссия) звучал так: "ORM на базе Linq — тормоза (относительно аналогичного кода на голых sql строках)". И этот тезис был полностью доказан в теме соответствующими тестами. Дальнейшей же обсуждение свелось к двум слегка холиварным направлениям:
S>>Еще раз в 100200 раз повторю, что запросы могут компилироваться и кэшироваться (если это не динамические запросы). Да и десериализация может компилироваться например с помощью Рослина или деревьев выражений (примеры я тебе уже кучу приводил) . Там много затрат идет на поиск объектов при не использовании AsNoTracking и еще куча подводных камней.
S>>Это будет ничем не медленнее голых SQL строк. Я тебе уже кучу примеров приводил.

_>Это всё слова. А тесты показывают другое. Да и не только тесты, но и примеры настоящих специалистов (а не форумных теоретиков), имеющих дело с сильно нагруженными системами.

Тесты как раз без AsNoTracking итд. Нужно смотреть где тормоза, а потом их обсуждать. Ты же берешь тесты и делаешь выводы без всякого профилирования, и говоришь о настоящих специалистах?. Есть другие тесты и с другими результатами.

Стоит так же сравнить CompiledQuery
http://stackoverflow.com/questions/4932594/when-should-i-use-a-compiledquery
И посмотреть где просадка. Пока у тебя одни домыслы.

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

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

_>>>Для написания скриптов C# (как и C++) очевидно хуже Питона (надеюсь не надо объяснять почему?). А для других целей я Питон особо и не использую.
S>> Надо. Я могу и на C# писать в стиле скриптов. При этом иметь и типизацию. Я могу сравнивать так как пишу и на 1С и на C#. C# очень приятный язык.
S>>Правда вот синтаксис Nemerle мне больше нравится, но что ж поделать эта дань засилью сишников.

_>Нуу накидай на C# например скриптик подключающийся параллельно к нескольким удалённым машинам (по ssh), копирующий в них некий проект и собирающий его там. Естественно с выводом всех сообщений об ошибках в локальную консоль. Сравним объём и читаемость твоего решения и решения на Питоне. )

Не занимаюсь таким, а изучать отдельно нет смысла.
_>>>Безусловно различные DSL'и гораздо удобнее универсальных языков в своих узких нишах.
S>> А вот C# прекрасно чувствует себя во многих нишах.

_>Естественно, т.к. C# — это не DSL, а полноценный универсальный язык. Хотя всё же набор доступных ему ниш несколько уже чем у большинства нативных языков в силу ограничений самой платформы .net (а точнее clr).
Так в этом есть и премущество, так как чем больше исключений, тем больше проблем при изучении не только языка, но и понимании чужого кода.

Хотя сейчас есть хоть и ограниченная, но общая для линукс Core .Net, андроид IOS Xamarin