Здравствуйте, ·, Вы писали:
_>>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. ))) ·>Только в идеальном мире. Производительность не аддитивна. Допустим ты сравниваешь C++ compile time vs .net reflection. А что если, например, JIT в .net сгенерит более эффективный код, который в итоге сработает быстрее?
Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом. Другое дело, что он может быть небольшим в сравнение с другими источниками тормозов или просто производительности может хватать и в таком варианте, так что не будет смысла беспокоиться.
А C++ тут вообще никто не трогал в сравнениях. )
·>Или более очевидно — время запроса 100ms±1%, на рефлексию тратится <10us. Как ты докажешь, что рефлексия что-то замедляет, а не ускоряет?
Здравствуйте, alex_public, Вы писали:
_>·>Или более очевидно — время запроса 100ms±1%, на рефлексию тратится <10us. Как ты докажешь, что рефлексия что-то замедляет, а не ускоряет?
_>Ну ускорять то она в любом случае не будет. )))
Она будет ускорять труд разработчика. Кроме того ты же сам выступаешь за статическую типизацию. Так вот при Linq она как раз родимая и присутствует, пусть и через типизированную прокси
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ikemefula, Вы писали:
I>>>В высоконагруженых используют аналогичные механизмы, только место EF будет другой ORM. AVK>>На rsdn используется не EF, а linq2db. Быстрее только руками. I>Всё равно ORM и linq.
Это к вопросу о высоконагруженных. linq2db до определенного предела вполне себе подходит для высоконагруженных применений. А дальше проблема будет не в linq2db, а в РСУБД в целом. Выше по нагрузке — хитрожопые хардкодные схемы с ручной кластеризацией, NoSql и самописные хранилища.
Здравствуйте, alex_public, Вы писали:
_>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, alex_public, Вы писали:
_>>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом.
НС>А теперь посмотрим на практику — http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html
Здравствуйте, alex_public, Вы писали:
_>·>Только в идеальном мире. Производительность не аддитивна. Допустим ты сравниваешь C++ compile time vs .net reflection. А что если, например, JIT в .net сгенерит более эффективный код, который в итоге сработает быстрее? _>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом. Другое дело, что он может быть небольшим в сравнение с другими источниками тормозов или просто производительности может хватать и в таком варианте, так что не будет смысла беспокоиться.
Да не важна конкретика, суть в том что перформанс системы нужно мерить целиком. Ведь что угодно может быть, например, Linq сможет что-то хитро соптимизировать и склеить меньше строк, что-то закешировать, создать меньше мусора для сборщика, и т.п. Понятно, что это можно будет реализовать кастомной лесенкой if-ов, склейкой и прочего, но тогда может сразу в маш-кодах писать?
_>А C++ тут вообще никто не трогал в сравнениях. ) _>·>Или более очевидно — время запроса 100ms±1%, на рефлексию тратится <10us. Как ты докажешь, что рефлексия что-то замедляет, а не ускоряет? _>Ну ускорять то она в любом случае не будет. )))
А доказать сможешь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Serginio1, Вы писали:
_>>Ну ускорять то она в любом случае не будет. ))) S> Она будет ускорять труд разработчика. Кроме того ты же сам выступаешь за статическую типизацию. Так вот при Linq она как раз родимая и присутствует, пусть и через типизированную прокси
Только вот во всех известных нормальных случаях переход от динамической типизации к статической увеличивает быстродействие. И только в реализациях sql через linq умудрились сделать наоборот. )))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну ускорять то она в любом случае не будет. ))) S>> Она будет ускорять труд разработчика. Кроме того ты же сам выступаешь за статическую типизацию. Так вот при Linq она как раз родимая и присутствует, пусть и через типизированную прокси
_>Только вот во всех известных нормальных случаях переход от динамической типизации к статической увеличивает быстродействие. И только в реализациях sql через linq умудрились сделать наоборот. )))
Дело в том, что получаемые данные не типизированы. Нужна надстройка и не одна.
А вот удобство использования перекрывает незначительные потери при использовании прокси.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Вообще то в данном контекте речь шла о сравнение вариант на C# с linq vs вариант на C# с голыми sql строками. И в данном случае все тормоза от работы с linq тут являются чистым оверхедом. НС>А теперь посмотрим на практику — http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html
Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. И они полностью подтверждают мои слова. Даже более того, я конечно ожидал десятков процентов тормозов, но не 50% для лучшей реализации и 500% для худшей (однако более популярной). Естественно такие радикальные цифры наблюдаются только для быстрых запросов. В случае же тяжёлых запросов величина оверхеда относительно времени исполнения самого запроса естественно снижается, до соответственно 10% в лучшей реализации и 100% в худшей. Что всё равно очень много на мой взгляд.
P.S. Цифры для EF конечно же вообще шокирующие. )))
P.P.S. Теперь будет куда тыкать носом всяких умников, которые тут болтают про бред или просто молча минусы рисуют... )))
_>P.S. Цифры для EF конечно же вообще шокирующие. ))) _>P.P.S. Теперь будет куда тыкать носом всяких умников, которые тут болтают про бред или просто молча минусы рисуют... )))
Прежде чем тыкать, сам поумней.
Почитай про AsNoTracking()
Здравствуйте, alex_public, Вы писали:
_>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. )))
Ты именно так и говоришь — указываешь рефлексию как единственную причину тормозов, кроме склейки строк.
Здравствуйте, alex_public, Вы писали:
_>Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. И они полностью подтверждают мои слова.
Вообще то полностью опровергают.
1 Узкое место это не компиляция запросов и рефлексия, а обычный маппинг.
2 в самых тяжелых(и самых важных) разницы между linq2db и ado просто нет. Это как раз та статистика, которая по твоим словам должна выжрать все ядра и расплавить сервер.
3 правильное кеширование нивелирует имеющуюся разницу, разве что EF так и останется тормозить, судьба у него такая.
Судя по результатам, единственная оптимизация, которую стоит делать на sql, это множество мелких запросов которые возвращают минимум данных. Это запросы вида "select * from users where id=xxx" и то сильно вряд ли, что это даст эффект при хорошем кешировании.
> Даже более того, я конечно ожидал десятков процентов тормозов, но не 50% для лучшей реализации и 500% для худшей (однако более популярной). Естественно такие радикальные цифры наблюдаются только для быстрых запросов. В случае же тяжёлых запросов величина оверхеда относительно времени исполнения самого запроса естественно снижается, до соответственно 10% в лучшей реализации и 100% в худшей. Что всё равно очень много на мой взгляд.
Ты для начала попробуй достичь этот предел. После правильного кеширования разницы между linq и sql вообще не будет. А в высоконагруженых приложениях узким местом станет сеть и сама база как таковая.
Здравствуйте, Ikemefula, Вы писали:
_>>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. ))) I>Ты именно так и говоришь — указываешь рефлексию как единственную причину тормозов, кроме склейки строк.
Ты здесь говоришь про тормоза Linq ORM или про тормоза всей итоговой системы в целом? )
Здравствуйте, Ikemefula, Вы писали:
_>>Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. И они полностью подтверждают мои слова. I>Вообще то полностью опровергают. I>1 Узкое место это не компиляция запросов и рефлексия, а обычный маппинг.
Ну естественно, что если ты запросишь из БД мегабайты данных, то любые оверхеды на формирования запроса и т.п. потеряются на фоне банальной перекачки этих данных. Только откуда такие запросы на практике? Чаще всего пользователям отдаётся 10-100 строк, если мы говорим о неком просмотре таблицы. А ещё чаще запросы возвращают ровно одну строку с конкретными данными. Кстати, такого измерения в данном тесте даже и не было (там минимум 10 строк) — было бы любопытно взглянуть... )))
I>2 в самых тяжелых(и самых важных) разницы между linq2db и ado просто нет. Это как раз та статистика, которая по твоим словам должна выжрать все ядра и расплавить сервер.
10% оверхеда там вообще то или у тебя плохо с арифметикой? ))) Причём это для самых запущенных случаев (сложный запрос с большим результатом). Да, и важность запроса (приоритет на оптимизацию) определяет скорее не его тяжестью, а его частотой использования — система может заработать намного быстрее в случае оптимизации простенького, но постоянно используемого запроса.
Здравствуйте, alex_public, Вы писали:
_>>>Ну вообще то фраза "раз рефлексия занимает время >0, то значит она источник тормозов" является идеально верной априори. ))) Вот если бы там стояло "она главный источник тормозов", то уже можно было бы смело придираться. ))) I>>Ты именно так и говоришь — указываешь рефлексию как единственную причину тормозов, кроме склейки строк.
_>Ты здесь говоришь про тормоза Linq ORM или про тормоза всей итоговой системы в целом? )
Не я, а ты. Ты говорил что тормозит linq ORM и назвал ажно две причиы — склейку строк и рефлексию.
Маппинг, к слову, ты даже не упомянул.
Здравствуйте, alex_public, Вы писали:
_>Ну естественно, что если ты запросишь из БД мегабайты данных, то любые оверхеды на формирования запроса и т.п. потеряются на фоне банальной перекачки этих данных. Только откуда такие запросы на практике? Чаще всего пользователям отдаётся 10-100 строк, если мы говорим о неком просмотре таблицы. А ещё чаще запросы возвращают ровно одну строку с конкретными данными. Кстати, такого измерения в данном тесте даже и не было (там минимум 10 строк) — было бы любопытно взглянуть... )))
Практика она разная в каждом случае. Что будет чаще, что реже — покажет профайлер. Часто используемые кейсы как раз и покроются правильным кешированием и другими методами, то есть, проблему будет составлять только промах в кеш.
Цена промаха — 0.1мс на один мелкий запрос.
Вобщем нет ничего того, о чем ты говорил, и узкое место не рефлексия и не склеивание строк, и разница совсем не та, запросы проблемные совсем не те, что ты указывал.
ВОбщем, всё не так как ты говорил.
I>>2 в самых тяжелых(и самых важных) разницы между linq2db и ado просто нет. Это как раз та статистика, которая по твоим словам должна выжрать все ядра и расплавить сервер.
_>10% оверхеда там вообще то или у тебя плохо с арифметикой? ))) Причём это для самых запущенных случаев (сложный запрос с большим результатом).
10% оверхеда это ни о чем. Ты ведь намекал что сервер должен расплавиться, это ужос-ужос и именно здесь ты хотел видеть SQL.
>Да, и важность запроса (приоритет на оптимизацию) определяет скорее не его тяжестью, а его частотой использования — система может заработать намного быстрее в случае оптимизации простенького, но постоянно используемого запроса.
Важно что оптимизация делается согласно приоритету, а не наличию-отсутствию рефлексии. Откуда берётся приоритет — дело десятое, может ручные замеры, может профайлер, может еще что, никому не интересно.
Здравствуйте, alex_public, Вы писали:
_>Вот, отлично! Наконец то не просто отзывы профессионалов на форуме, а уже специальные замеры. _>P.S. Цифры для EF конечно же вообще шокирующие. ))) _>P.P.S. Теперь будет куда тыкать носом всяких умников, которые тут болтают про бред или просто молча минусы рисуют... )))
Именно, что "специальные".
Замеры "у нас тут голый sql" vs "ORM c прикрученым change tracking" а потом получают "шокирующие цифры" говорят скорее о квалификации тестирующих, а вовсе не о том, что тестируется.
Здравствуйте, Ikemefula, Вы писали:
I>>>Ты именно так и говоришь — указываешь рефлексию как единственную причину тормозов, кроме склейки строк. _>>Ты здесь говоришь про тормоза Linq ORM или про тормоза всей итоговой системы в целом? ) I>Не я, а ты. Ты говорил что тормозит linq ORM и назвал ажно две причиы — склейку строк и рефлексию.
Если говорить про тормоза ORM и рефлексию, то да, подтверждаю эти свои слова. ) А вот склейку строк я причиной тормозов не называл. )))
I>Маппинг, к слову, ты даже не упомянул.
Потому что это не оверхед ORM'a, а по сути полезная часть работы — это логичнее включить во время исполнения запроса.
Здравствуйте, Ikemefula, Вы писали:
I>Практика она разная в каждом случае. Что будет чаще, что реже — покажет профайлер. Часто используемые кейсы как раз и покроются правильным кешированием и другими методами, то есть, проблему будет составлять только промах в кеш. I>Цена промаха — 0.1мс на один мелкий запрос.
С кэшем вне БД основная проблема в том, что надо очень чётко отслеживать все места в программе (или даже нескольких программах), которые меняют данные, чтобы не забыть поставить там сброс кэша. Так что это на самом деле весьма тонкий вопрос, не решаемый мановением руки.
Кстати, я заметил, что во всех этих обсуждениях мы затрагивали только варианты запроса данных из БД. А если перейти к добавлению данных в БД, то всё становится ещё гораздо интереснее... )))
_>>10% оверхеда там вообще то или у тебя плохо с арифметикой? ))) Причём это для самых запущенных случаев (сложный запрос с большим результатом). I>10% оверхеда это ни о чем. Ты ведь намекал что сервер должен расплавиться, это ужос-ужос и именно здесь ты хотел видеть SQL.
Ну для начала 10% — это нижний предел (а верхний 50%) и то для не самого популярного инструмента. Т.е. на практике с этим инструментом будет в среднем 20-30%, как я приблизительно и ожидал.
Вопрос много это или мало очевидно зависит от масштабов сервиса. К примеру если он работает у тебя на сотне узлов (это сейчас вполне обыденная вещь, а не нечто космическое как у гугла или яндекса), то можешь сам посчитать экономию от выключения 20% машин. ))) Ну это естественно если у сервиса узким местом является доступ к БД, что впрочем весьма распространённое явление.
I>Важно что оптимизация делается согласно приоритету, а не наличию-отсутствию рефлексии. Откуда берётся приоритет — дело десятое, может ручные замеры, может профайлер, может еще что, никому не интересно.
Оптимизацию можно сделать автоматическую, ещё на стадии разработки — не использовать linq. ))) Ну во всяком случае при работе на C#, в котором недоступны средства для работы с типизированным sql без существенного оверхеда.
Здравствуйте, Yoriсk, Вы писали:
Y>Именно, что "специальные". Y>Замеры "у нас тут голый sql" vs "ORM c прикрученым change tracking" а потом получают "шокирующие цифры" говорят скорее о квалификации тестирующих, а вовсе не о том, что тестируется.
Ну это не ко мне претензии, т.к. тесты делал не я и даже ссылку на них притащил не я. Но замечу, что даже если говорить только о linq2db, то оверхед в 10-50% (в зависимости от тяжести запроса) всё равно является очень существенным.
