Здравствуйте, alex_public, Вы писали:
_>Так и есть. Фанаты linq что тогда были неадекватные, что сейчас. В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии.
У тебя linq синоним EF. Есть два разных бенчмарка. В одном указано, что linq2db на порядок или два быстрее EF, и почти такой же быстрый, как и ADO. В другом — тоже самое про dapper.
Из этого ты делаешь вывод, что dapper быстрее любого linq-провайдера на том основании, что он быстрее EF.
Где логика ?
Ты ухитрился слить 2 разных высказывания в одно
а. даппер лучше любого linq-провайдера
б. даппер есть наилучший способ эффективно использовать DBMS
Вот здесь есть противоречия:
1 Нулевой оверхед на сервере совершенно не означает наилучшее использование сети между сервером и базой данных
2 Нулевой оверхед на сервере совершенно не означает наилучшее использование самого движка базы данных
То есть, ты пытаешься оптимизировать исключительно вызывающий код, без оглядки на самую важную вещь.
Почему даппер в SO показал хороший результат, очевидно — ручные оптимизации проблем 1 и 2 и очень, очень, очень простая, тривиальная модель — форум.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Danchik, Вы писали:
D>>Здесь сделали по правильному D>>http://pastebin.com/8mXh36P1
I>Шота даппер тут совсем хило выглядит
Даппер и не был супер-быстр.
Он был первым в этой области и полностью удовлетворял (и сейчас удовлетворяет) SO.
От этого все автоматически посчитали, что даппер быстрее всех.
На самом деле быстрее всех linq2db.
Здравствуйте, Sinclair, Вы писали:
_>>Проект с подобной архитектурой обречён быть тормозом. S>. S>Это проект со склейкой SQL строк обречён быть тормозом. Вы про производительность приложений с DBMS лучше не пишите ничего. Не так стыдно потом будет перечитывать.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sinclair, Вы писали:
_>>>Проект с подобной архитектурой обречён быть тормозом. S>>. S>>Это проект со склейкой SQL строк обречён быть тормозом. Вы про производительность приложений с DBMS лучше не пишите ничего. Не так стыдно потом будет перечитывать.
_>Аргументировано. )))
Вообще что ты сам начал с безапелляционного заявления, которое категорически неверно.
Здравствуйте, alex_public, Вы писали:
_>>>Проект с подобной архитектурой обречён быть тормозом. S>>. S>>Это проект со склейкой SQL строк обречён быть тормозом. Вы про производительность приложений с DBMS лучше не пишите ничего. Не так стыдно потом будет перечитывать.
_>Аргументировано. )))
Твой пример непонятно как трактовать. Вот ты привел данные, что асп работал втрое дольше sql. Что это значит, по твоему ?
Здравствуйте, Sinclair, Вы писали:
_>>Эм, а зачем подменять эту тонкую прослойку в развёрнутом приложение? ) S>Ну вот например несколько экземпляров нашего развёрнутого приложения с год назад было решено перевести с SQLite на MS SQL — потому что используемые объёмы выросли, а SQLite, как ни крути, непригоден для промышленного использования. Это вполне себе валидный бизнес-сценарий.
Ну и?) Чтобы предусмотреть подобное в приложение с помощью подобной шаблонной библиотечке придётся вставить в неё целых две дополнительные строчки (одна чтение конфигурации и другая банальный if). Возможно в какой-то из .net ORM эти строчки уже входят в саму библиотеку, но я не думаю, что это можно считать каким-то существенным достижением. )))
Здравствуйте, Serginio1, Вы писали:
S> Кстати а почему ты не упомянул про Dapper S>https://github.com/StackExchange/dapper-dot-net S> Вот тебе типизированные запросы о которых ты мечтал. При этом быстрые.
И ServiceStack.OrmLite и Dapper работают не через Linq. А я здесь говорил о тормознутости именно такого решения, а не вообще всех ORM в .Net. В том же linq2sql, не смотря на название, есть вариант работы без linq, который очень эффективен.
Здравствуйте, Ikemefula, Вы писали:
I>>>Относительно чего тормозят, mov ax, bx ? _>>Уже раз 100 говорилось — относительно прямого доступа к БД. I>То есть, относительно голых запросов без какого либо кеширования. Правильно ? I>А с кешированием как быть ?
Ты вообще в курсе как проводятся измерения? ) Почитай что-нибудь о теории эксперимента. )
_>>Зато не синтические и с беспредельным кешированием на Stack Overflow, но что-то выводы одинаковые... ))) I>Даппер они начали использовать еще в незапамятные времена. Кроме того, им вообще не нужны никакие возможности от ORM. Им, по большому счет, им ORM не нужен.
А что такое "возможности ORM"? ) Ты вообще там случаем не забыл как расшифровывается эта аббревиатура? )
Здравствуйте, alex_public, Вы писали:
I>>А с кешированием как быть ?
_>Ты вообще в курсе как проводятся измерения? ) Почитай что-нибудь о теории эксперимента. )
В курсе. Потому и спрашиваю — почему ты игнорируешь кеширование ?
_>>>Зато не синтические и с беспредельным кешированием на Stack Overflow, но что-то выводы одинаковые... ))) I>>Даппер они начали использовать еще в незапамятные времена. Кроме того, им вообще не нужны никакие возможности от ORM. Им, по большому счет, им ORM не нужен.
_>А что такое "возможности ORM"? ) Ты вообще там случаем не забыл как расшифровывается эта аббревиатура? )
Не забыл, а ты, похоже, не помнишь. Покажешь, как даппер искаропки умеет маппинг наследования ? Опаньки !
Здравствуйте, Danchik, Вы писали:
_>>Даже если забыть о том, что это не совсем одинаковые запросы... Ты в начале покажи мне соответствующий linq код, из которого данные запросы генерируются для разных СУБД (и перечисли их с указанием какой sql для какой СУБД генерируется). D>Ну делать нам тут не... D>Вот посмотри видео, где Игорь показывает как генерятся разные CRUD запросы для разных баз данных. Занимательная штука. Или просто послушай музычку и расслабся ) D>https://www.youtube.com/watch?v=m--oX73EGeQ
Посмотрел. Приятная музыка, симпатичное видео. Но никаких заявленных умных оптимизаций я не увидел. В примере демонстрируются только очевидные разные записи (в соответствие с особенностями синтаксиса конкретной СУБД) одних и тех же запросов. Т.е. то, что делает любой подобный инструмент.
Так что, кто-нибудь мне всё же покажет анонсированные умные оптимизации под конкретную СУБД? ) Смену join на что-то ещё там и т.п. Или это была просто болтовня?
[Skip]
_>Так что, кто-нибудь мне всё же покажет анонсированные умные оптимизации под конкретную СУБД? ) Смену join на что-то ещё там и т.п. Или это была просто болтовня?
Хватит тролить. Времени на твое убеждение нету, итак сидишь на плюсах
Берешь ставишь разные серваки, какие тебе интересны, разворачиваешь базы. Ставишь LinqPad, ставишь это https://github.com/linq2db/linq2db.LINQPad
И играйся себе, ищи минусы. Плюсы мы для себя давно нашли.
Здравствуйте, gandjustas, Вы писали:
_>>В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии. Единственное отличие этой дискуссии от прошлой в том, что в той из реальных оценок присутствовали только слова пары человека (в том числе тебя) с форума. А в этот раз тут можно найти гораздо более интересные замеры (опять же не мои), типа таких http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html. G>Прекрасная статья. Сравнивается быстродействие двух Linq-провайдеров и мапперов. Получается что linq2db им практически не проигрывает. EF проигрывает, но в абсолютных велечинах речь идет о десятых долях микросекунд на объект.
Что-то ты как-то странно разглядываешь эти результаты. Я например вижу в основном сравнение linq и не linq решений разных библиотек. И даже для лучшей из них (link2db) проигрыш идёт от 8 до 93 процентов в зависимости от запроса, а про худшую (EF) даже говорить страшно. )))
_>>Или же вот такие https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/ любопытные данные (это уже я нашёл) о том что применяют реальные профи из мира .net. G>"Реальные профи" применяются Dapper, который по моим замерам оказался медленнее linq2db.
У тебя в тестах linq2db и прямой доступ к БД существенно опережает. ))) Что как бы не способствует доверию к ним. Вот в результатах по ссылке выше цифры приблизительно совпадают (естественно linq2db в режиме sql строк, а не linq). Ну а по Dapper'у я видел похоже цифры (что он на пару процентов медленнее прямого доступа). Соответственно я бы предположил, что все эти три инструмента (ADO.NET, linq2db(в режиме sql строк), Dapper) работают с приблизительно одинаковым быстродействием, плюс минус несколько процентов.
G>А до этого те же профи Linq2SQL использовали.
Ну да, в самом начале свой работы, когда посещаемость была ещё слабенькая. А как пошли реальные нагрузки, так резко выбросили его. Кстати, там вообще забавно. Изначально же у них был исключительно стек MS (одна машина с SQL Server и пара машин с приложением на .net). А если глянуть на их текущую архитектуру, то там всё больше linux машин и приложений на других языках. Будет забавно, если ещё через несколько лет они вообще уйдут от технологий MS. Тогда пропадёт практически единственный аргумент сторонников этого стека в дискуссиях о высоконагруженных системах. )))
_>>Если ты посмотришь внимательно, то именно это (ну без добавки про головы некоторых людей) я и говорил в данной темке, причём неоднократно. Очевидно, что для всяких слабонагруженных систем linq отлично подходит. Могу показать тебе ссылки на эти сообщения, если сам не увидел. ) G>Я посмотрел внимательно и ты ничего про нагрузки не говорил. И вряд ли сможешь что-нить внятное сказать. У тебя высоконагруженных систем никогда не было.
Ну вот например несколько дней назад прямой в этой темке я написал:
Ну я собственно уже писал, что для реализации домашней странички васи пупкина или же для мелкого внутрикорпоративного приложения все эти накладные расходы непринципиальны и соответственно linq идеально подходит для таких решений. Только это совершенно не означает его нетормознутость. )))
G>Но самое главное не это, а то, что никакая система изначально не является высоконагруженной, зато любую систему надо сделать быстрее. Именно тут linq помогает.
Безусловно. Правда потом (когда придёт нагрузка) ещё потребуется время на вычищение всего этого из проекта. Вот на SO уже несколько лет как вычищают и до сих пор ещё следы остаются.
G>>>Причем в нагруженных системах легко эти тормоза обойти за счет компиляции запросов, а в головах людей эта проблема нерешаемая. _>>Ха, а вот тут уже совсем другой расклад появляется — здесь удобство становится даже похуже голых sql строк. G>обоснуй _>>Я уже не говорю об инструментах из других языков, в которых есть возможность иметь полностью удобный вид без малейших накладных расходов. G>В других языках нет ничего, что хотя бы на сотую долю похоже на Linq по функциональности и удобству использования.
Мы это с тобой подробно обсуждали в той старой темке. Ты тогда накидывал различные задачки, подразумевая что их невозможно решить другими инструментами. Но все решения были тебе продемонстрированы. Но итогового вывода ты так и не признал и просто разговор закончился. Не вижу смысла повторять это всё по новому кругу, т.к. наверняка результат будет тот же самый.
Здравствуйте, Ikemefula, Вы писали:
_>>Так и есть. Фанаты linq что тогда были неадекватные, что сейчас. В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии. I>У тебя linq синоним EF. Есть два разных бенчмарка. В одном указано, что linq2db на порядок или два быстрее EF, и почти такой же быстрый, как и ADO. В другом — тоже самое про dapper. I>Из этого ты делаешь вывод, что dapper быстрее любого linq-провайдера на том основании, что он быстрее EF. I>Где логика ?
У linq2db есть два режима работы: через sql строки и через linq. В первом режиме он очень хорош и не уступает ADO. Dapper судя по их цифрам тоже держится в районе этих же цифр.
Если же мы используем linq2db в режиме linq, то сразу появляются существенные накладные расходы.
Про EF же говорить вообще смешно. Там и в режиме sql строк дикое отставание, а при подключение linq вообще жуть начинается.
Так что тебе не понятно с логикой? Вроде как вполне ясная и очевидна картина.
I>Ты ухитрился слить 2 разных высказывания в одно I>а. даппер лучше любого linq-провайдера I>б. даппер есть наилучший способ эффективно использовать DBMS
Ты это, общайся с голосами в твоей голове сам. Мне их приписывать не надо. )))
Здравствуйте, Ikemefula, Вы писали:
_>>Ты вообще в курсе как проводятся измерения? ) Почитай что-нибудь о теории эксперимента. ) I>В курсе. Потому и спрашиваю — почему ты игнорируешь кеширование ?
Не похоже) Чистота эксперимента явно является для тебя пустым звуком.
_>>А что такое "возможности ORM"? ) Ты вообще там случаем не забыл как расшифровывается эта аббревиатура? ) I>Не забыл, а ты, похоже, не помнишь. Покажешь, как даппер искаропки умеет маппинг наследования ? Опаньки !
Тебе напомнить кто отвечает вопросом на вопрос? )
Ну а насчёт предложения мне показать что-то на Dapper'е — это вообще смешно. ))) Ты не спутал меня случаем с .net программистами? ) У меня собственно даже самого .net'a на компьютере уже давно нет, ну кроме обычного дистрибутива, встроенного в ОС. Благо он позволяет скомпилировать примеры в командной строке, так что тестовые примеры можно проверять. )))
Здравствуйте, Danchik, Вы писали:
_>>Так что, кто-нибудь мне всё же покажет анонсированные умные оптимизации под конкретную СУБД? ) Смену join на что-то ещё там и т.п. Или это была просто болтовня? D>Хватит тролить. Времени на твое убеждение нету, итак сидишь на плюсах
Кто троллит то? ) Это я тут рассказывал о каких-то чудесах оптимизации запросов к БД с помощью Linq? ) Как раз я всегда отвечаю за свои слова. И если я высказал какой-то тезис, то всегда готов его аргументировать кодом, тестом или ещё чем-то. Большинство моих собеседников уже давно убедилось в этом. В отличие от некоторых местных болтунов, которые любят высказывать громкие слова, но при первом же требование показать конкретный пример благополучно сливаются. И если таких товарищей не ловить за руку, то скоро форумом вообще будет невозможно пользоваться.
D>Берешь ставишь разные серваки, какие тебе интересны, разворачиваешь базы. Ставишь LinqPad, ставишь это https://github.com/linq2db/linq2db.LINQPad D>И играйся себе, ищи минусы. Плюсы мы для себя давно нашли.
Ох, как феерично. ))) Т.е. ты предлагаешь мне заняться поиском доказательств верности высказываний оппонентов? ) Причём таких сомнительных, что даже если бы я вдруг сошёл с ума и занялся этим, то вполне мог бы ничего не найти (т.к. их вероятно не существует в природе). Это просто шедевр) Давно не видел таких заманчивых предложений. )))
Здравствуйте, alex_public, Вы писали:
I>>В курсе. Потому и спрашиваю — почему ты игнорируешь кеширование ?
_>Не похоже) Чистота эксперимента явно является для тебя пустым звуком.
Ты намекаешь на какой то особо вырожденный случай. В высоконагруженых системах такого точно не будет, что бы запросы миновали кеширование.
Вопрос — как твоя синтетика соотносится с реальностью ?
_>>>А что такое "возможности ORM"? ) Ты вообще там случаем не забыл как расшифровывается эта аббревиатура? ) I>>Не забыл, а ты, похоже, не помнишь. Покажешь, как даппер искаропки умеет маппинг наследования ? Опаньки !
_>Тебе напомнить кто отвечает вопросом на вопрос? )
Ты ведь намекаешь денно и нощно. А мне почему нельзя ?
_>Ну а насчёт предложения мне показать что-то на Dapper'е — это вообще смешно. ))) Ты не спутал меня случаем с .net программистами? ) У меня собственно даже самого .net'a на компьютере уже давно нет, ну кроме обычного дистрибутива, встроенного в ОС. Благо он позволяет скомпилировать примеры в командной строке, так что тестовые примеры можно проверять. )))
Вот-вот. Поинтересуйся вопросом и значением аббревиатуры, сразу поймешь что с чем ты сравниваешь
Здравствуйте, alex_public, Вы писали:
_>>>Так и есть. Фанаты linq что тогда были неадекватные, что сейчас. В ответ на высказанный мимоходом очевидный тезис о тормознутости данного инструмента они начинают длинные и бесплодные дискуссии. I>>У тебя linq синоним EF. Есть два разных бенчмарка. В одном указано, что linq2db на порядок или два быстрее EF, и почти такой же быстрый, как и ADO. В другом — тоже самое про dapper. I>>Из этого ты делаешь вывод, что dapper быстрее любого linq-провайдера на том основании, что он быстрее EF. I>>Где логика ?
_>У linq2db есть два режима работы: через sql строки и через linq. В первом режиме он очень хорош и не уступает ADO. Dapper судя по их цифрам тоже держится в районе этих же цифр.
_>Если же мы используем linq2db в режиме linq, то сразу появляются существенные накладные расходы.
http://pastebin.com/8mXh36P1
_>Так что тебе не понятно с логикой? Вроде как вполне ясная и очевидна картина.
I>>Ты ухитрился слить 2 разных высказывания в одно I>>а. даппер лучше любого linq-провайдера I>>б. даппер есть наилучший способ эффективно использовать DBMS
_>Ты это, общайся с голосами в твоей голове сам. Мне их приписывать не надо. )))
а. Ты сказал, что даппер работает нормально в отличие от linq. Далее, ты сказал, что все linq тормозят. Ergo -> даппер работает лучше любого linq-провайдера.
Тесты показывают, что это не так.
б. попутал, ты говорил это про свою плюсовую библиотечку. Раз нулевой оверхед, значит и сетью, и с базой все в полном порядке.
Здравствуйте, alex_public, Вы писали:
_>Кто троллит то? ) Это я тут рассказывал о каких-то чудесах оптимизации запросов к БД с помощью Linq? )
Ты говорил про чудеса ручной оптимизации. Количество колонок твоя мулька сократить уже не может. Опаньки !
Декомпозицию она не умеет — соответственно снова ручные оптимизации.
> Как раз я всегда отвечаю за свои слова. И если я высказал какой-то тезис, то всегда готов его аргументировать кодом, тестом или ещё чем-то.
Да, от трех недель до года ждать надо. А по некоторым вещам за тобой должок уже больше двух лет.
_>Ох, как феерично. ))) Т.е. ты предлагаешь мне заняться поиском доказательств верности высказываний оппонентов? )
Тебе же дали результаты, ты сказал, что они некошерные. Ищи сам тогда
.
