Здравствуйте, IT, Вы писали:
_>>Предложенный тобой тест не имеет никакого отношения к обсуждаемой теме (тормозам от Linq), потому как в нём используются не только разные методы формирования запросов, но и разные методы обработки получаемых данных. Так что результаты подобного теста вообще ни о чём полезном сказать не могут. IT>Это как? Приведённые тесты более точно отражают реалии. Если тебе не эти тесты, потому что они тебя не устраивают, то это твоя личная проблема.
Ещё раз повторяю нормальным русским языком: эти тесты не имеют ни малейшего отношения к оценке накладных расходов от linq (не от ORM linq2db, а от записи запросов с помощью linq!). Потому что в них используются не только разные способы задания запросов, но и разные способы обработки полученных данных, которые так же влияют на измеряемое время. Соответственно из измерения данной интерференции двух разных факторов абсолютно невозможно сделать какие-либо выводы о величине одного из них (а ведь именно её мы обсуждаем в данной теме).
IT>Можешь написать свой вариант и мы его обсудим.
Я вроде как ясно сформулировал прямо в предыдущем сообщение. Возьми этот свой тест и замени в нём код с ADO на код с linq2db row sql. Я сам не могу провести подобный тест, т.к. у меня не установлены соответствующие инструменты. А вот для тебя это дело нескольких секунд. И твоё явное нежелание провести подобный тест наводит на вполне однозначные мысли... )))
Здравствуйте, IT, Вы писали:
_>>С абстрактной объектной моделью и у linq всё плохо. IT>Плохо по сравнению с чем? С твоими абстрактными фантазиями? Не спорю, мои абстрактные фантазии тоже иногда бывают такими абстрактными...
Ммм, я правильно понял, что ты считаешь, что на linq может быть удобна работа например с графами? )
P.S. Да, у SQL тут дела естественно не особо лучше. Но мой собеседник то начал говорить уже не про СУБД, а про объектные модели!
P.P.S Кстати, как раз при использование подобных сложных объектных моделей появляется дополнительный смысл (помимо независимости от типа СУБД) в построение полноценного DAL.
Здравствуйте, alex_public, Вы писали:
_>Я вроде как ясно сформулировал прямо в предыдущем сообщение. Возьми этот свой тест и замени в нём код с ADO на код с linq2db row sql. Я сам не могу провести подобный тест, т.к. у меня не установлены соответствующие инструменты. А вот для тебя это дело нескольких секунд. И твоё явное нежелание провести подобный тест наводит на вполне однозначные мысли... )))
Вот результаты теста, который тебе не нравится, обычный linq запрос против ADO
LINQ: 100000 in 00:00:05.7321425
ADO: 100000 in 00:00:05.5328326
Здесь разница, внимание, 3.6% ! Все что ты можешь выжать с помощью linq raw sql только эти 3.6% Более того, абсолютные числа такого порядка, что обработка одного http запроса целиком end-2-end даст много большее влияние. Ты JSON будешь серилизовать/десерилизовать будешь дольше, чем эти 3.6%
Здравствуйте, alex_public, Вы писали:
I>>Пример — на платформе Java hibernate использует HQL I>>
I>>Hibernate Query Language (HQL) is an object-oriented query language, similar to SQL, but instead of operating on tables and columns, HQL works with persistent objects and their properties
_>Мне сейчас не охота заниматься словесными играми, так что в этот раз разберём вопрос быстро и просто. Ответь просто на один вопрос: Dapper — это ORM или нет? ) Думаю твой ответ сразу закончит данную дискуссию, т.к. после него уже больше не получится развлекаться демагогическими увёртками. )
Нет, не ORM. Я это говорю тебе в разной форме уже три месяца. dapper и подобные вещи иногда называются micro-ORM. Фактически — примитивный маппер. При всем этом он сливает linq2db.
Здравствуйте, alex_public, Вы писали:
_>Меня всё больше пугают проблемы с твоим зрением. ))) Прямо по данной ссылке указанное тобой описывается как: _>
_>An alternative SQL interface to prepared statements is available. This interface is not as efficient as using the binary protocol through a prepared statement API, but requires no programming because it is available directly at the SQL level
Тебя просили показать базу, которая не использует SQL для prepare. MySQL может работать и так и так. Бинарный протокол появился совсем недавно, от SQL варианта никто пока не отказывается.
_>Ну и чтобы до тебя окончательно дошло: в sql варианте для предкомпилированного запроса используется уникальное текстовое имя, а в нормальном (родными средствами) режиме естественно никаких уникальных имён не требуется.
Если ты забыл, то именно я рассказывал тебе, как именно работает prepare. Это не столько оптимизация сетевого протокола, сколько принудительное удержание плана запроса в кеше. И это создаёт определенные проблемы и ограничения.
Здравствуйте, alex_public, Вы писали:
_>Насчёт критичности для 1% (понятно что цифра условная) — это верно. Но и для очень многих других накладные расходы тоже актуальны, т.к. это всё на практике стоит вполне реальных денег. Причина же использования всех этих тормознутых решений довольно банальна — затраты на оплату работы "оптимизатора" в большинстве случаев больше, чем затраты на оплату ресурсов для этих самых накладных расходов.
Чушь. К сожалению, большинство программистов ещё не освоили толком LINQ. Да что там LINQ. Подавляющее большиство толком не знает что такое yield return. Т.е. народ даже спецификацию языка не читал, на котором пишет 10 лет. А ты про оптимизаторов.
_>Однако если появится инструмент (собственно такое уже не раз бывало во многих направлениях), позволяющий легко (без привлечения крутых "оптимизаторов") разрабатывать продукт без соответствующих накладных расходов, то вся индустрия очень быстро начнёт переползать на него...
Никто и не утверждает, что LINQ — это идеальное решение. Вовсе нет. Но это на сегодняшний день — лучшее решение. Возможно ли сделать лучше? Конечно. Никаких технических проблем для этого не существует. Могу в деталях рассказать, что для этого нужно.
_>Можешь глянуть например здесь: http://vibed.org — вполне интересный продукт сам по себе. Ну а если тебе всё же лень копаться, то прокомментирую: там используется полноценный шаблонизатор html страниц (с синтаксисом типа Jade), в котором страницы компилируются в бинарный исполняемый файл (сервера). Так вот это происходит без всяких препроцессоров и т.п., просто силами самого компилятора D. )))
Посмотри на Razor, все эти идеи явно спёрты оттуда. Хотя он и сам скорее всего много чего попёр у других.
_>Ну и D — это опять же не единственный пример. В том же Rust'e макросы способны например такое: https://github.com/sfackler/rust-postgres-macros. Понятно что это немного не то, что мы обсуждали в данной темке. Но если уж можно такое, то без проблем реализуется и статический генератор запросов. Надо просто сесть и написать. )))
Кому он нужен статический генератор запросов?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alex_public, Вы писали:
_>Угу, "галантерейщик и кардинал — это сила... "))) Может Java и слегка обходит C/C++ по популярности (при этом прямая конкуренция у них минимальная), но в любом случае они оба где-то очень далеко от C#. )))
Ты забыл дабавить "в моей альтернативной мега вселенной".
_>Это всего лишь твоё личное мнение, которое по моему личному мнению имеет мало что общего с истиной. )
Хамишь, дружище? Видимо аргументы закончились.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alex_public, Вы писали:
_>А вот для тебя это дело нескольких секунд. И твоё явное нежелание провести подобный тест наводит на вполне однозначные мысли... )))
Для меня может и несколько секунд, но только после того как удастся расшифровать поток твоего сознания. Честно, ничего не понял
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ikemefula, Вы писали:
I>Вот результаты теста, который тебе не нравится, обычный linq запрос против ADO I>LINQ: 100000 in 00:00:05.7321425 I>ADO: 100000 in 00:00:05.5328326 I>Здесь разница, внимание, 3.6% ! Все что ты можешь выжать с помощью linq raw sql только эти 3.6% Более того, абсолютные числа такого порядка, что обработка одного http запроса целиком end-2-end даст много большее влияние. Ты JSON будешь серилизовать/десерилизовать будешь дольше, чем эти 3.6%
Угу, только если ты внимательно глянешь на тест, то увидишь, что ADO там используется в существенно неоптимальном варианте (в моменте маппинга). В то время как внутри linq2db оно используется как раз в оптимальном. Т.е. мы заменили одни накладные расходы другими и в итоге получили близкие цифры. Кстати, ещё повезло (или подогнано как надо), что результат ADO не оказался тормознутее — неудобно было бы такое объяснять... )))
Это всё конечно забавные фокусы, но такое характерно скорее для каких-нибудь маркетологов впаривающих свою продукцию. А в подобном обсуждение это скорее напоминает неуважение к собеседникам.
Хотя судя по тому, что ты легко повёлся и даже теперь цитируешь эти результаты, определённые основания для такого поведения могут быть... )
Здравствуйте, Ikemefula, Вы писали:
_>>Мне сейчас не охота заниматься словесными играми, так что в этот раз разберём вопрос быстро и просто. Ответь просто на один вопрос: Dapper — это ORM или нет? ) Думаю твой ответ сразу закончит данную дискуссию, т.к. после него уже больше не получится развлекаться демагогическими увёртками. ) I>Нет, не ORM. Я это говорю тебе в разной форме уже три месяца. dapper и подобные вещи иногда называются micro-ORM. Фактически — примитивный маппер. При всем этом он сливает linq2db.
ОК, тогда всё понятно. ) Значит у тебя просто своя личная альтернативная терминология по этому вопросу. Тогда у нас собственно и нет никакого спора (по терминлогиям споров быть не может — о них просто договариваются и всё).
Здравствуйте, Ikemefula, Вы писали:
_>>Меня всё больше пугают проблемы с твоим зрением. ))) Прямо по данной ссылке указанное тобой описывается как: _>>
_>>An alternative SQL interface to prepared statements is available. This interface is not as efficient as using the binary protocol through a prepared statement API, but requires no programming because it is available directly at the SQL level
I>Тебя просили показать базу, которая не использует SQL для prepare. MySQL может работать и так и так. Бинарный протокол появился совсем недавно, от SQL варианта никто пока не отказывается.
Она как раз и работает без всякого SQL. ) Если из своего приложения А SQL синтаксис добавлен для возможности поиграться с данной функциональностью из консоли.
Ну и насчёт первичности тоже можно легко всё понять. Как ты думаешь, это уникальные текстовые имена работают через внутренние дескрипторы или наоборот дескрипторы работают через генерацию внутренних текстовых имён? )))
Здравствуйте, IT, Вы писали:
IT>Никто и не утверждает, что LINQ — это идеальное решение. Вовсе нет. Но это на сегодняшний день — лучшее решение. Возможно ли сделать лучше? Конечно. Никаких технических проблем для этого не существует. Могу в деталях рассказать, что для этого нужно.
Для определённой целевой аудитории — безусловно. ) С этим как бы никто тут и не спорил. )))
_>>Ну и D — это опять же не единственный пример. В том же Rust'e макросы способны например такое: https://github.com/sfackler/rust-postgres-macros. Понятно что это немного не то, что мы обсуждали в данной темке. Но если уж можно такое, то без проблем реализуется и статический генератор запросов. Надо просто сесть и написать. ))) IT>Кому он нужен статический генератор запросов?
Хорошо, переформулирую твоими же словами. ))) Можно получить type safety, но без накладных расходов в рантайме. )
Здравствуйте, IT, Вы писали:
_>>А вот для тебя это дело нескольких секунд. И твоё явное нежелание провести подобный тест наводит на вполне однозначные мысли... ))) IT>Для меня может и несколько секунд, но только после того как удастся расшифровать поток твоего сознания. Честно, ничего не понял
Гм, странно что может быть непонятного в таком очевидном объяснение и тем более повторенном два раза. Ну да ладно, повторю в третий раз, совсем по простому.
В приведённом тобой тесте идёт сравнение исполнения через linq2db запроса записанного через linq с исполнением через ADO запроса записанного текстовой строкой. Такое сравнение не может быть использовано при обсуждение вопроса накладных расходов вносимых записью запроса через linq (почему подробно объяснено в предыдущих сообщениях данной темы). А чтобы получить корректный результат, достаточно провести в тесте сравнение исполнения через linq2db запроса записанного через linq и исполнения через linq2db запроса записанного текстовой строкой. С учётом наличия у тебя того готового теста, сделать подобное для тебя реально пара секунд.
P.S. Кстати, в обсуждаемых здесь результатах тестов (не твоих, а тех самых, по ссылке) как раз были приведены все 3 результата (ADO, linq2db linq, linq2db row sql), что и позволило делать корректные выводы.
Здравствуйте, alex_public, Вы писали:
I>>Вот результаты теста, который тебе не нравится, обычный linq запрос против ADO I>>LINQ: 100000 in 00:00:05.7321425 I>>ADO: 100000 in 00:00:05.5328326 I>>Здесь разница, внимание, 3.6% ! Все что ты можешь выжать с помощью linq raw sql только эти 3.6% Более того, абсолютные числа такого порядка, что обработка одного http запроса целиком end-2-end даст много большее влияние. Ты JSON будешь серилизовать/десерилизовать будешь дольше, чем эти 3.6%
_>Угу, только если ты внимательно глянешь на тест, то увидишь, что ADO там используется в существенно неоптимальном варианте (в моменте маппинга).
Тебе сто раз дали ответ. В тестах __типичный__ код. Никто и никогда не мапит индексами. Даже полные дебилы не занимают такой хренью.
>В то время как внутри linq2db оно используется как раз в оптимальном. Т.е. мы заменили одни накладные расходы другими и в итоге получили близкие цифры. Кстати, ещё повезло (или подогнано как надо), что результат ADO не оказался тормознутее — неудобно было бы такое объяснять... )))
Да, сравнивается типичный с типичным.
_>Это всё конечно забавные фокусы, но такое характерно скорее для каких-нибудь маркетологов впаривающих свою продукцию. А в подобном обсуждение это скорее напоминает неуважение к собеседникам. Хотя судя по тому, что ты легко повёлся и даже теперь цитируешь эти результаты, определённые основания для такого поведения могут быть... )
Ты видел когда нибудь типичный код на ADO ? Сколько раз ты видел мапинг индексами а не именами ? В продакше, а не твоих наколеночных поделках.
Здравствуйте, alex_public, Вы писали:
_>>>Мне сейчас не охота заниматься словесными играми, так что в этот раз разберём вопрос быстро и просто. Ответь просто на один вопрос: Dapper — это ORM или нет? ) Думаю твой ответ сразу закончит данную дискуссию, т.к. после него уже больше не получится развлекаться демагогическими увёртками. ) I>>Нет, не ORM. Я это говорю тебе в разной форме уже три месяца. dapper и подобные вещи иногда называются micro-ORM. Фактически — примитивный маппер. При всем этом он сливает linq2db.
_>ОК, тогда всё понятно. ) Значит у тебя просто своя личная альтернативная терминология по этому вопросу. Тогда у нас собственно и нет никакого спора (по терминлогиям споров быть не может — о них просто договариваются и всё).
Здравствуйте, alex_public, Вы писали:
_>Ну и насчёт первичности тоже можно легко всё понять. Как ты думаешь, это уникальные текстовые имена работают через внутренние дескрипторы или наоборот дескрипторы работают через генерацию внутренних текстовых имён? )))
Это не важно. Основной профит не в сетевом протоколе, а в особой работе с кешем планов запросов.
Здравствуйте, alex_public, Вы писали:
_>Хорошо, переформулирую твоими же словами. ))) Можно получить type safety, но без накладных расходов в рантайме. )
Тебе уже сто раз объясняли, что без накладных не получится. Во-первых, в зависимости от значения параметра запрос нужно будет перестраивать. Во-вторых, совсем совсем статические запросы — это далеко не все запросы в приложении. Часто приходится формировать запросы динамически. А это означает, что во время компиляции тебе придётся не готовый SQL формировать на выходе, а в лучшем случае некий SQL AST, по сути тот же Expression Tree и потом разбирать его в runtime.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Во-вторых, совсем совсем статические запросы — это далеко не все запросы в приложении.
Сколько статических по твоим оценкам?
IT>Часто приходится формировать запросы динамически.
Чем это конкретно обусловлено?
Я к тому, что если это обусловлено например тем что итоговый запрос собирается в разных частях программы (о чём в этих темах часто и говорят), то для этого динамика не обязательна.
Если нам не помогут, то мы тоже никого не пощадим.
