Здравствуйте, Andir, Вы писали:
A>Мои поздравления IT и всем участникам проекта BLToolkit
Ага, спасибо. Мы порвали их всех!
С другой стороны, учитывая сколько времени мы потратили на оптимизацию, вычищение боксинга и затрат на приведение типов, было бы стыдно проиграть.
Код для Multiple CUD тестов был дописан уже по ходу, по мотивам тестов. Поэтому они и выглядят вроде как естественно, но работают быстро С другой стороны такая корова пригодится и самому, как-то раньше в голову не пришло. Спасибо создателям тестов за идею и возможность ещё раз взглянуть на API и полезные возможности библиотеки.
С Linq тестами пока не всё так гладно, там ещё много работы (вот если бы MS раньше созналась в том, что они бросают L2S), но думаю, что современем мы и тут не ударим в грязь лицом.
Если нам не помогут, то мы тоже никого не пощадим.
Недавно на сайте ormbattle.net появилось сравнение производительности популярных .NET ORM. В частности, присутствуют NHibernate, Entity Framework, Open Access и другие. Как думаете, насколько приведенные результаты адекватны?
S>P.S. вполне возможно что под local cache мы понимаем разные вещи. Я рассматриваю кэш как автономное хранилище данных, заведённое для того чтобы централизованно ими управлять/хранить состояние приложения.
Вроде-бы и я так же. Просто похоже, что на его использование мы смотрим по-разному
Ну ладно, все равно его пока нет. Зато я сегодня написал большой пост на тему того, что уже почти есть: http://blog.dataobjects.net (DisconnectedState там более-менее описан).
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, meowth, Вы писали:
IT>>>А я говорю, что всё так. Это значит, что всё действительно так? M>>Не знаю Вы какое отношение имете к тестам и к тому, что они тестируют? IT>К тестам пока никакого, к тому что они тестируют, т.е. к ORM самое непосредственное.
Ну я имел в виду NHibernate, конечно же
IT>>>Любой тест показывает именно то, что он тестирует и не важно устраивают эти результаты проигравших или нет. Лично для меня все тесты вполне адекватны и весьма показательны. Если NH тормозит на материализации, то это сразу видно и мне всё равно какой вклад этот тормоз будет вносить в приложение. M>>А для меня -- нет IT>А Вы какое отношение имете к тестам и к тому, что они тестируют?
Я -- активный advanced пользователь NHibernate )
M>>Но я понял политику, ага. Отвечу так: в деревне VillaRiba посмотрели на примеры real-world приложений, заценили тул, выбрали оптимальный, и давно сдали проект. А в деревне Villabadjo продолжают самозабвенно надрач%вать на статсы материализации. IT>Про ваши деревни я не в курсе. Но про вполне конкретные "оптимальные тулы" наслышан от товарищей и насмотрелся сам. Тормоз, он и есть тормоз. Теперь это ещё и тестами подтверждается.
Мне все равно, что говорят вам товарищи. It works for me, что поделать
И да -- вы неправильно говорите. Вернее, неполно. Правильно будет так: "... теперь это еще и тестами подтверждается, которые никогда не встречаются в реальных задачах"
M>>В смысле, если бы были жалобы на низкую производительность, ими бы занимались в первую очередь -- проекту не год и не два. IT> А то, что показали тесты — это позор. Я на месте разработчиков NH, как честный человек, просто бы застрелился.
Я даже не знаю, радоваться или расстраиваться, что вы не разработчик NHibernate ) Кстати, чего это им стреляться -- Nhibenate вышел неплохим середнячком по тестам.
M>>P.S. Сколько приложений бегают на DataObjects? А Hibernate тем временем -- корпоративный стандарт. IT>Это где он стандарт? В Java? Да за ради бога. Кстати, знаешь как в Java решаются проблемы производительности Hibernate? В основном тупым наращиванием железа.
Да, да, аргумент, ага. В java все плохо. Впрочем, давайте не будем распыляться, я знаю, что вы java-ненавистник
Жду пруфлинк на такой случай -- где все уперлось в Hibernate, и понадобилось железо.
M>>Так они и сказали: да, мы тормозим, но это by design. Есть пост об этом. Разработчики считают это ходом, вы -- кривым архитектурным решением. IT>Ходом? А почему тогда EF имеет вполне приличную производительность при схожей функциональности?
Вы опять недоговариваете.
Во-первых, правильно будет так: "... почему EF имеет приличную производительность на синтетеических тестах, которые не встречаются в реальных приложениях?".
Во-вторых, вы на табличку-то хоть посмотрите -- да-да, прямо счас. EF и NHibernate примерно одинаковы по производительности (причем NHIbernate, в основном, впереди). Единственная "засада" -- с материализацией сущностей на крупных объемах данных в одной сессии работой с БД, да. Но это вот почему: сессии NHibernate не расчитаны на batch processing -- они OLTP, небольшими порциями: create — process — discard. А в тестах происходит именно это -- многотысячи объектов грузятся в одну и ту же ISession. Поэтому я не спорю -- NHIbernate не слишком сильно подходит для такого типа сценариев.
M>>Ни мое, ни ваше мнение впрочем не повлияет на разработчиков IT>Я и не собираюсь на него влиять. Если разработчики тормозного тула способны лишь на тормозной дизайн, то мне не интересны ни они, ни их тул.
Посмотрите еще раз на таблицу. Этот тормозной тул в основном уделал EF.
Но вы это не мне говорите, вы разработчикам NHibernate напишите. Куда им до BLToolkit, тупым разработчикам NHibernate Кстати, вы много проектов на NHibernate сделали, или так -- не пробовал, но осуждаю? А то я посмотрел комменты ваши на RSDN касательно NHIbernate, вы нигде не пишете, что пробовали, зато везде НЕНАВИСТЬ!!11адин
M>>Они не собираются _дискредитировать_ тесты. Они лишь говорят о том, что судить по результатам _этих_ тестов о применимости (и неприменимости) того же NHibernate в реальных приложениях -- неверно. IT>А где в тестах речь о применимости? Тесты, как я уже сказал, показывают только то, что они тестируют. Выводы каждый делает сам и чем он при этом руководствуется его личное дело, будь это либо тесты, либо устные заверения разработчиков и сочувствующих.
Абсолютно согласен. И еще раз согласен. Трижды согласен, если хотите. Но эти тесты -- они не для разработчика, понимаете. Они -- для того, кто будет определять стратегию проекта, для менеджера, если так угодно. А он не будет разбираться -- он просто вставит цифры в презентацию и скажет: "Ё-ма-на, DataObject.NET, однозначно!".
Предлагаю завершить холивар и вам сходить на ORMBattle.net еще раз. "Завершить" -- это значит ответить на мои реплики (если это нужно), не задавая встречных вопросов, а то мы будем общаться до второго пришествия -- это интересно и познавательно, но на тесты не влияет, к сожалению
Здравствуйте, meowth, Вы писали:
M>Не должно быть так -- по душе. Должно быть -- объективны или нет. Если несколько человек -- Brion, Rahien, Maulo говорят, что что-то не так -- это значит, что действительно что-что не так.
А я говорю, что всё так. Это значит, что всё действительно так?
Любой тест показывает именно то, что он тестирует и не важно устраивают эти результаты проигравших или нет. Лично для меня все тесты вполне адекватны и весьма показательны. Если NH тормозит на материализации, то это сразу видно и мне всё равно какой вклад этот тормоз будет вносить в приложение. Тормоза видны? Видны. Значит идите и работайте или признайте, что да, мы тормозим, но считаем это вполне приемлемым для себя и для наших пользователей.
Если же у ребят есть свои сценарии, где их ORM показывает себя с лучшей стороны, то давайте добавим эти тесты и посмотрим результаты. Если же они способны лишь на дискредитацию тестов, то как минимум это не спортивно.
Тест, в качестве одного большого приложения ничего не даст по той простой причине, что охватить одним приложением множество сценариев, в котором каждый ORM сможет себя проявить просто нереально. Это будет столько разных архитектур, сколько ORM. И зависеть тесты будут не от возможностей ORM, а от квалификации разработчиков. Например, если взять тест, где определённые данные из справочника будут выводится на веб-страничку, то победит не лучшая ORM, а тот, кто додумается включить кешь страницы и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, meowth, Вы писали:
M>Ну я имел в виду NHibernate, конечно же
К счастью, к этому я отношения не имею.
IT>>А Вы какое отношение имете к тестам и к тому, что они тестируют? M>Я -- активный advanced пользователь NHibernate )
Сочувствующий. Понятно.
M>Мне все равно, что говорят вам товарищи. It works for me, что поделать
О! Вот с этого и надо было начинать. Надо сразу говорить, тормоза меня вполне устраивают, а не рассуждать о синтетичности и встречаемости в жизни тех или иных сценариев.
M>И да -- вы неправильно говорите. Вернее, неполно. Правильно будет так: "... теперь это еще и тестами подтверждается, которые никогда не встречаются в реальных задачах"
Я говорю всё правильно и не надо за меня перевирать. Я и сам могу, если понадобится
M>>>В смысле, если бы были жалобы на низкую производительность, ими бы занимались в первую очередь -- проекту не год и не два. IT>> А то, что показали тесты — это позор. Я на месте разработчиков NH, как честный человек, просто бы застрелился. M>Я даже не знаю, радоваться или расстраиваться, что вы не разработчик NHibernate ) Кстати, чего это им стреляться -- Nhibenate вышел неплохим середнячком по тестам.
Ну да. Только вот операции выборки, которые, кстати, чаще всего встречаются в "реальных" задачах, в основном на порядок медленнее эталона.
M>Да, да, аргумент, ага. В java все плохо. Впрочем, давайте не будем распыляться, я знаю, что вы java-ненавистник
Ну вот, началось уже обсуждение личностей. Я не ненавистник, я джава-индеферентник, мне она абсолютно безразлична, разве что иногда поржать. Впрочем, так же как и NH.
M>Жду 'пруфлинк' на такой случай -- где все уперлось в Hibernate, и понадобилось железо.
Пруфлинк? Можно круче устроить. Возмём, например, мой прошлый проект с BofAS. Устроит? Приходи в гости, я тебя лично познакомлю с разработчиками, пообщаешься, они тебе расскажут всё, что думают и о Java и о Hibernate.
M>Вы опять недоговариваете. M>Во-первых, правильно будет так: "... почему EF имеет приличную производительность на синтетеических тестах, которые не встречаются в реальных приложениях?".
Жду пруфлинк на определение синтетичности, на реальности и встречаемости. А то получается у тебя какие-то особенные приложения.
M>Во-вторых, вы на табличку-то хоть посмотрите -- да-да, прямо счас.
Смотрю, материализация отличается в 20 раз. 20 РАЗ! Это — позор!
M>EF и NHibernate примерно одинаковы по производительности (причем NHIbernate, в основном, впереди). Единственная "засада" -- с материализацией сущностей на крупных объемах данных в одной сессии работой с БД, да. Но это вот почему: сессии NHibernate не расчитаны на batch processing -- они OLTP, небольшими порциями: create — process — discard. А в тестах происходит именно это -- многотысячи объектов грузятся в одну и ту же ISession. Поэтому я не спорю -- NHIbernate не слишком сильно подходит для такого типа сценариев.
Да он для многих типов сценариев не подходит. Вы бы лучше там подумали и предложили свои сценарии, это было бы гораздо интереснее и продуктивнее, чем кидаться какашками в ORMBattle и теоретизировать на тему жизни, встречаемости и применимости.
IT>>Я и не собираюсь на него влиять. Если разработчики тормозного тула способны лишь на тормозной дизайн, то мне не интересны ни они, ни их тул. M>Посмотрите еще раз на таблицу. Этот тормозной тул в основном уделал EF. M>Но вы это не мне говорите, вы разработчикам NHibernate напишите. Куда им до BLToolkit, тупым разработчикам NHibernate
BLToolkit, не кстати тут упомянутый, не совсем ORM, но по производительности порвёт тот же NH как тузик грелку. Только ошмётки будут в разные стороны разлетаться
M>Кстати, вы много проектов на NHibernate сделали,
0.0
Я не использую инструменты, которые мне навязывают архитектуру моих приложений. Процессом забивания гвоздей должен руководить плотник, а не молоток.
M>или так -- не пробовал, но осуждаю? А то я посмотрел комменты ваши на RSDN касательно NHIbernate, вы нигде не пишете, что пробовали, зато везде НЕНАВИСТЬ!!11адин
Но-но-но, это уже начинает тянуть на клевету. Давай не будем так низко опускаться. Твой NH всего лишь тул, как можно ненавидеть тул, например, как можно ненавидеть пассатижи? Ненавидеть можно тех кто его использует, но не понятно за что. Этих людей нужно не ненавидеть, а пожалеть, сирых и убогих, с искалеченной хайбернейтом судьбой.
M>Абсолютно согласен. И еще раз согласен. Трижды согласен, если хотите. Но эти тесты -- они не для разработчика, понимаете. Они -- для того, кто будет определять стратегию проекта, для менеджера, если так угодно. А он не будет разбираться -- он просто вставит цифры в презентацию и скажет: "Ё-ма-на, DataObject.NET, однозначно!".
Эти тесты прежде всего для разработчиков ORM. Не нужно учить людей как им правильно жить, не нужно им навязывать своё мнение, которое по сути прикрывает промахи в архитектуре инструмента и лень. Нужно сесть и заняться оптимизацией производительности инструмента, тогда таким разработчикам будет почёт и уважуха. Кстати, разработчики других тулов так и сделали. Нытьё слышится только от команды NH. Стыдно должно быть.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AlexGX, Вы писали:
AGX>Недавно на сайте ormbattle.net появилось сравнение производительности популярных .NET ORM. В частности, присутствуют NHibernate, Entity Framework, Open Access и другие. Как думаете, насколько приведенные результаты адекватны?
Today we've got a new leader It is BLToolkit. Few days ago its author (Igor Tkachev) has contacted us, and we provided him with full access to our source code repository & Google groups. Today I was able to run his performance tests, and actually was QUITE surprised — his results are almost ideal; BLToolkit is nearly as fast as plain SQL!
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, alexyakunin!
S>TCP-E в этом плане будет интересней TCP-C, но и куда более громоздким в реализации — сущностей там слегка больше
Угу, сами думаем, чего делать с ними...
S>P.S. Слегка удивила реакция "Нет это плохие тесты. И вообще все тесты плахие." Взрослые вроде люди...
Согласен полностью.
S>P.P.S. Лёгкий оффтоп: DataObjects позиционируются как UoW фреймфорк (аналогично EF) или как local cache (аналогично датасетам)? Просто ищется нечто из второй группы (с биндингом, валидацией по всему кэшу, маппингом на хранимые процедуры etc)...
Как UoW фреймвок — хотя различий с NH — масса; например, у нас нет dirty checking, и мы всегда знаем, что и как изменено; затраты на откат состояния у нас нулевые.
С другой стороны, как раз сейчас мы приделываем к нему local cache в нескольких ипостасиях. И в финале будет очень крут: у нас уже есть своя собственная БД в памяти — с индексами, оптимизатором запросов и т.п. (а это значит, в этом локальном кеше запросы будут работать ~ так же). Sync + ее улучшенная версия и станут идеальным local cache. Пока же мы делаем обычный DisconnectedState (тот же локальный кеш, но без запросов — тоже полезен иногда, т.к. создать его заметно проще, чем полноценную БД в памяти), + понемногу работаем над Sync.
Здравствуйте, meowth, Вы писали:
IT>>А я говорю, что всё так. Это значит, что всё действительно так? M>Не знаю Вы какое отношение имете к тестам и к тому, что они тестируют?
К тестам пока никакого, к тому что они тестируют, т.е. к ORM самое непосредственное.
IT>>Любой тест показывает именно то, что он тестирует и не важно устраивают эти результаты проигравших или нет. Лично для меня все тесты вполне адекватны и весьма показательны. Если NH тормозит на материализации, то это сразу видно и мне всё равно какой вклад этот тормоз будет вносить в приложение. M>А для меня -- нет
А Вы какое отношение имете к тестам и к тому, что они тестируют?
M>Но я понял политику, ага. Отвечу так: в деревне VillaRiba посмотрели на примеры real-world приложений, заценили тул, выбрали оптимальный, и давно сдали проект. А в деревне Villabadjo продолжают самозабвенно надрач%вать на статсы материализации.
Про ваши деревни я не в курсе. Но про вполне конкретные "оптимальные тулы" наслышан от товарищей и насмотрелся сам. Тормоз, он и есть тормоз. Теперь это ещё и тестами подтверждается.
M>В смысле, если бы были жалобы на низкую производительность, ими бы занимались в первую очередь -- проекту не год и не два.
А кто сказал, что жалоб не было? Только это не так просто как кажется. Над оптимизацией производительности нужно было работать с самого начала, с первых строк кода. Это я вам как 'собаковод' говорю. А то, что показали тесты — это позор. Я на месте разработчиков NH, как честный человек, просто бы застрелился.
M>P.S. Сколько приложений бегают на DataObjects? А Hibernate тем временем -- корпоративный стандарт.
Это где он стандарт? В Java? Да за ради бога. Кстати, знаешь как в Java решаются проблемы производительности Hibernate? В основном тупым наращиванием железа.
M>Так они и сказали: да, мы тормозим, но это by design. Есть пост об этом. Разработчики считают это ходом, вы -- кривым архитектурным решением.
Ходом? А почему тогда EF имеет вполне приличную производительность при схожей функциональности?
M>Ни мое, ни ваше мнение впрочем не повлияет на разработчиков
Я и не собираюсь на него влиять. Если разработчики тормозного тула способны лишь на тормозной дизайн, то мне не интересны ни они, ни их тул.
M>Они не собираются _дискредитировать_ тесты. Они лишь говорят о том, что судить по результатам _этих_ тестов о применимости (и неприменимости) того же NHibernate в реальных приложениях -- неверно.
А где в тестах речь о применимости? Тесты, как я уже сказал, показывают только то, что они тестируют. Выводы каждый делает сам и чем он при этом руководствуется его личное дело, будь это либо тесты, либо устные заверения разработчиков и сочувствующих.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, achmed, Вы писали: A>Можно подойти сбоку, например, с помощью profiler api перехватывать вызовы классов ADO.NET. A>Мне бОльшая сложность видится в автоматическом анализе кода SQL.
Вот этого — не надо. Автоматический анализ кода SQL здесь крайне противопоказан, по крайней мере — велосипедный.
Вот чем имеет смысл мериться — так это статистикой СУБД.
То есть, берём участников забега №1, 2, 3 и т.п.
Протоколируем исполненный ими SQL.
Прогоняем полученный SQL через SQL Server (отдельно от маппера)
Смотрим Total I/O Cost и Total CPU Cost.
По желанию — смотрим фактическое Total Execution Time.
А сам код SQL анализировать незачем. Там может быть произвольное количество полуслучайных факторов, которые нам неинтересны до тех пор, пока СУБД способна их устранить.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexGX
AGX>Недавно на сайте ormbattle.net появилось сравнение производительности популярных .NET ORM. В частности, присутствуют NHibernate, Entity Framework, Open Access и другие. Как думаете, насколько приведенные результаты адекватны?
Учитывая что отдельные ормапперы умудряются выигрывать в 2-3 раза у SqlClient на апдейте/удалении — сомневаюсь%) Как минимум что-то они там не то нахимичили...
Ага. Они использовали SqlClient чтобы показать оверхед непосредственно orm'a. Отсюда и слегка неестественный код (материализация объектов для обновления/удаления etc). В остальном особых косяков не вижу.
Учитывая что авторы работают в http://x-tensive.com/ очень интересно было бы увидеть их DataObjects
Right now I can list just few decisions we've already made and done:
1. Remove DataObjects.Net from results published on this web site.
We decided to avoid arguing with some people believing the benchmarks provided here are designed for this product or intentionally made to market it. Unfortunately, that was the simplest way to prove the idea behind this website and its results are of greater importance for us. There are still tests for it in source code, but we don't publish its results here any more.
S>Right now I can list just few decisions we've already made and done:
S>1. Remove DataObjects.Net from results published on this web site.
S>We decided to avoid arguing with some people believing the benchmarks provided here are designed for this product or intentionally made to market it. Unfortunately, that was the simplest way to prove the idea behind this website and its results are of greater importance for us. There are still tests for it in source code, but we don't publish its results here any more.
S>Моё уважение
Ага, уважение Они первоначально опубликовали свои результаты, и вы не поверите, кто был победителем: в среднем -- в 2-4 раза обходили _всех_ остальных на _всех_ тестах. Их пристыдили, и они убрали свои результаты
S>>Right now I can list just few decisions we've already made and done:
S>>1. Remove DataObjects.Net from results published on this web site.
S>>We decided to avoid arguing with some people believing the benchmarks provided here are designed for this product or intentionally made to market it. Unfortunately, that was the simplest way to prove the idea behind this website and its results are of greater importance for us. There are still tests for it in source code, but we don't publish its results here any more.
S>>Моё уважение
M>Ага, уважение Они первоначально опубликовали свои результаты, и вы не поверите, кто был победителем: в среднем -- в 2-4 раза обходили _всех_ остальных на _всех_ тестах. Их пристыдили, и они убрали свои результаты
Враки, господа
Да, мы выигрывали, но не на всех тестах, и далеко не всегда в 2-4 раза. Но мы были всегда в пределах 10-20% от лидера на каждом тесте.
DO4 мы убрали вовсе не потому, что "пристыдили". Стыдиться нам на самом деле нечего. Просто это был самый простой способ охладить накал.
Если интересно, сейчас мы ведем переговоры с теми, кто там в лидерах. Думаю, и так ясно, что раз протестов с их стороны нет, они смотрят на все это несколько иначе, чем банда фанатов NHibernate с Ореном во главе. Я думаю, Орен и Франс многое потеряют, оставшись за бортом. Впрочем... Криками и результатов все равно не изменишь. Да, NH популярен, но вовсе не быстр, и им надо было просто признать это. Мы и так "заточили" их тесты так, что это больше на хакерство похоже стало: http://ormbattle.net/index.php/faqs/73-are-nhibernate-tests-really-optimal-is-there-any-cheating-making-them-run-slower.html
И про DO4: он появится там, как только большей части публики станет совершенно ясно, что никаких читов в тестах нет. И вот тогда у вас будет возможность повторить еще раз фразу "мое уважение!"
A>Если интересно, сейчас мы ведем переговоры с теми, кто там в лидерах. Думаю, и так ясно, что раз протестов с их стороны нет, они смотрят на все это несколько иначе, чем банда фанатов NHibernate с Ореном во главе. Я думаю, Орен и Франс многое потеряют, оставшись за бортом.
ИМНО он (Орен) против таких синтетических методов(типа вставка/удаление записей в цикле), он и предложил мерять на конкретном приложении. Привели бы его цитаты про эти бенчмарки, например:
But that is not really relevant. Tight loop benchmarks for frameworks as complex as OR/Ms are always going to lie. The only way to really create a benchmark is to create a full blown application with several backend implementations. That is still a bad idea, as there are still plenty of ways to cheat. All you have to do is to look at the PetShop issues from 2002/3 to figure that one out.
Здравствуйте, cadet354, Вы писали:
A>>Если интересно, сейчас мы ведем переговоры с теми, кто там в лидерах. Думаю, и так ясно, что раз протестов с их стороны нет, они смотрят на все это несколько иначе, чем банда фанатов NHibernate с Ореном во главе. Я думаю, Орен и Франс многое потеряют, оставшись за бортом. C>ИМНО он (Орен) против таких синтетических методов(типа вставка/удаление записей в цикле), он и предложил мерять на конкретном приложении. Привели бы его цитаты про эти бенчмарки, например: C>
C>But that is not really relevant. Tight loop benchmarks for frameworks as complex as OR/Ms are always going to lie. The only way to really create a benchmark is to create a full blown application with several backend implementations. That is still a bad idea, as there are still plenty of ways to cheat. All you have to do is to look at the PetShop issues from 2002/3 to figure that one out.
C>а то сразу фанатик...
Не-не-не, давайте разберемся, что он тут говорит (он это не один раз повторил, кстати):
— Этот бенчмарк не соотестствует действительности; бенчмарки с простыми циклами — не для ОРМ
— Единственный путь сделать нормальный бенчмарк — сделать полноценное приложение с несколькими бекендами под разные ОРМ
— Нет, даже это — отстой, т.к. и в этом случае слишком много способов зачитить. Вспомните про бенчмарки ПетШопа 2002-2003 года.
Мораль: сделать показательный бенчмарк для ОРМ, по словам Орена, вообще невозможно!
A>Не-не-не, давайте разберемся, что он тут говорит (он это не один раз повторил, кстати): A>- Этот бенчмарк не соотестствует действительности; бенчмарки с простыми циклами — не для ОРМ
тут я с ним согласен. A>- Единственный путь сделать нормальный бенчмарк — сделать полноценное приложение с несколькими бекендами под разные ОРМ
аналогично A>- Нет, даже это — отстой, т.к. и в этом случае слишком много способов зачитить. Вспомните про бенчмарки ПетШопа 2002-2003 года. A>Мораль: сделать показательный бенчмарк для ОРМ, по словам Орена, вообще невозможно!
ну тут его занесло MS да и другие, например делает такие бенчи и поддерживают целые форумы с обсуждением, и в отличие от тестов в цикле дают хоть какое-то представление.
В тесты не смотрел, может у вас и показательнее примеры есть, но по чтению блога сложилось такое впечатление, что именно с этим он и не согласен.
A>Более того, он много раз говорил, что производительность у ОРМ вообще не важна, и при этом он старательно избегает давать прямой ответ на вот этот пост: http://ormbattle.net/index.php/blog/88-are-results-of-this-test-suite-really-important-part-1-why-i-dont-believe-oren-eini.html
ну так он вроде дал ответ A>Предлагаю, кстати, подождать с комментариями недельку. Думаю, там станет совершенно ясно, кому наши бенчмарки по душе, а кому — поперек горла.
и там вы схлестнулись в коментариях, я правда не понял, что ты хочешь ему доказать,что в цикле хибернайт будет сливать? так это и так понятно было
foreach (var o in query) {
o.Value++;
statelessSession.Update(o);
}
такие update в цикле не несут никакой полезной нагрузки,в дикой природе не встречаются, навскидку и не вспомню когда подобный код писал(но это моя практика, возможно все). Орен там еще профайл продает к хибернайту, и тут вы с циклами разгоняете людей от хибернайта.
P.S. с Nhibernate знаком плохо, не сложилось как-то с ним, не понравился, использую bltoolkit, но это не ORM (сейчас на проекте linq2sql т.к. написано на нем много и переписывать в ближайшее время точно не будем).
Здравствуйте, alexyakunin, Вы писали:
A>Здравствуйте, cadet354, Вы писали:
A>Не-не-не, давайте разберемся, что он тут говорит (он это не один раз повторил, кстати): A>- Этот бенчмарк не соотестствует действительности; бенчмарки с простыми циклами — не для ОРМ A>- Единственный путь сделать нормальный бенчмарк — сделать полноценное приложение с несколькими бекендами под разные ОРМ A>- Нет, даже это — отстой, т.к. и в этом случае слишком много способов зачитить. Вспомните про бенчмарки ПетШопа 2002-2003 года.
A>Мораль: сделать показательный бенчмарк для ОРМ, по словам Орена, вообще невозможно!
Хм, не знаю, откуда вы эту мораль вытащили. Ждем пруфлинк на цитаты про то, что сделать корректный показательный бенчмарк вообще невозможно. Тут он говорит только о трудностях, связанных с посторением таких бенчмарков, не более -- в связи с тем, что у каждого ORM существует оптимальный сценарий, есть нечаянный (или намеренный) риск сделать так, что остальные отстанут, и это будет нечестно.
A>Более того, он много раз говорил, что производительность у ОРМ вообще не важна, и при этом он старательно избегает давать прямой ответ на вот этот пост: http://ormbattle.net/index.php/blog/88-are-results-of-this-test-suite-really-important-part-1-why-i-dont-believe-oren-eini.html
Ну и что, что он так говорил? Меня, например, тоже не интересует быстродействие ORM, меня интересует его отрицательный вклад в общее быстродействие системы. Если с ORM №1 это 0.5%, а c ORM №2 -- 0.1%, то явно, что выбирать между 1 и 2 я буду не по скорости, а по каким-то другим критериям -- цена, learning curve, тулы и т.п. Это и хочет сказать Oren: постройте приложение и зацените.
A>Предлагаю, кстати, подождать с комментариями недельку. Думаю, там станет совершенноте ясно, кому наши бенчмарки по душе, а кому — поперек горла.
Не должно быть так -- по душе. Должно быть -- объективны или нет. Если несколько человек -- Brion, Rahien, Maulo говорят, что что-то не так -- это значит, что действительно что-что не так.
Здравствуйте, AlexGX, Вы писали:
AGX>Добрый день.
AGX>Недавно на сайте ormbattle.net появилось сравнение производительности популярных .NET ORM. В частности, присутствуют NHibernate, Entity Framework, Open Access и другие. Как думаете, насколько приведенные результаты адекватны?
Срач, срач и ещё раз срач. В итоге всё равно все останутся при своих мнениях — так что в чём смысл?
Здравствуйте, meowth%)
M>Ага, уважение Они первоначально опубликовали свои результаты, и вы не поверите, кто был победителем: в среднем -- в 2-4 раза обходили _всех_ остальных на _всех_ тестах. Их пристыдили, и они убрали свои результаты
Ну падумаешь подогнали фреймворк под тест
Всё равно ведь малаццы. TCP-E обещают (которым никто кроме МС не меряется потому как там условия пореальней чем в TCP-C).
Здравствуйте, alexyakunin!
A>Враки, господа
A>Да, мы выигрывали, но не на всех тестах, и далеко не всегда в 2-4 раза. Но мы были всегда в пределах 10-20% от лидера на каждом тесте.
О! День добрый! Прошу прощения за предыдущий пост, не видел ваших ответов.
Очень интересно как поведут себя ормапперы на сложных тестах — где добавится батчинг, отношения между сущностями, сложные запросы и т.п.
Вопросы про выигрыш у SqlClient снимаются — почитал то что написано на вашей главной (кстати в Опере 9.62 на 1024x768 косяк: правая колонка заползает на текст)
TCP-E в этом плане будет интересней TCP-C, но и куда более громоздким в реализации — сущностей там слегка больше
P.S. Слегка удивила реакция "Нет это плохие тесты. И вообще все тесты плахие." Взрослые вроде люди...
P.P.S. Лёгкий оффтоп: DataObjects позиционируются как UoW фреймфорк (аналогично EF) или как local cache (аналогично датасетам)? Просто ищется нечто из второй группы (с биндингом, валидацией по всему кэшу, маппингом на хранимые процедуры etc)...
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, alexyakunin, Вы писали:
A>>Не-не-не, давайте разберемся, что он тут говорит (он это не один раз повторил, кстати): A>>- Этот бенчмарк не соотестствует действительности; бенчмарки с простыми циклами — не для ОРМ C>тут я с ним согласен. A>>- Единственный путь сделать нормальный бенчмарк — сделать полноценное приложение с несколькими бекендами под разные ОРМ C>аналогично A>>- Нет, даже это — отстой, т.к. и в этом случае слишком много способов зачитить. Вспомните про бенчмарки ПетШопа 2002-2003 года. A>>Мораль: сделать показательный бенчмарк для ОРМ, по словам Орена, вообще невозможно! C>ну тут его занесло MS да и другие, например делает такие бенчи и поддерживают целые форумы с обсуждением, и в отличие от тестов в цикле дают хоть какое-то представление. C>В тесты не смотрел, может у вас и показательнее примеры есть, но по чтению блога сложилось такое впечатление, что именно с этим он и не согласен.
A>>Более того, он много раз говорил, что производительность у ОРМ вообще не важна, и при этом он старательно избегает давать прямой ответ на вот этот пост: http://ormbattle.net/index.php/blog/88-are-results-of-this-test-suite-really-important-part-1-why-i-dont-believe-oren-eini.html C>ну так он вроде дал ответ A>>Предлагаю, кстати, подождать с комментариями недельку. Думаю, там станет совершенно ясно, кому наши бенчмарки по душе, а кому — поперек горла. C>и там вы схлестнулись в коментариях, я правда не понял, что ты хочешь ему доказать,что в цикле хибернайт будет сливать? так это и так понятно было C>
C>foreach (var o in query) {
C>o.Value++;
C>statelessSession.Update(o);
C>}
C>
C>такие update в цикле не несут никакой полезной нагрузки,в дикой природе не встречаются, навскидку и не вспомню когда подобный код писал(но это моя практика, возможно все). Орен там еще профайл продает к хибернайту, и тут вы с циклами разгоняете людей от хибернайта.
C>P.S. с Nhibernate знаком плохо, не сложилось как-то с ним, не понравился, использую bltoolkit, но это не ORM (сейчас на проекте linq2sql т.к. написано на нем много и переписывать в ближайшее время точно не будем).
M>Хм, не знаю, откуда вы эту мораль вытащили. Ждем пруфлинк на цитаты про то, что сделать корректный показательный бенчмарк вообще невозможно. Тут он говорит только о трудностях, связанных с посторением таких бенчмарков, не более -- в связи с тем, что у каждого ORM существует оптимальный сценарий, есть нечаянный (или намеренный) риск сделать так, что остальные отстанут, и это будет нечестно.
Я даже искать не буду, возму то, что есть:
"The only way to really create a benchmark is to create a full blown application with several backend implementations. That is still a bad idea, as there are still plenty of ways to cheat. All you have to do is to look at the PetShop issues from 2002/3 to figure that one out."
И для вас выделю суть:
"The _only_ way to _really create_ a benchmark is ... _That is still a bad idea_, as there are still plenty of ways to cheat. All you have to do is to look at ... to figure that one out."
M>Ну и что, что он так говорил? Меня, например, тоже не интересует быстродействие ORM, меня интересует его отрицательный вклад в общее быстродействие системы. Если с ORM №1 это 0.5%, а c ORM №2 -- 0.1%, то явно, что выбирать между 1 и 2 я буду не по скорости, а по каким-то другим критериям -- цена, learning curve, тулы и т.п. Это и хочет сказать Oren: постройте приложение и зацените.
Среди этих несколько человек есть Oren и Fabio (разработчики NH), которые напрямую заинтересованы в результате теста. Предлагаю вам всерьез подумать, чего бы они сказали, если бы NH там была на высоте, или просто #1. Я думаю, пост был бы один, и совершенно другого характера. А тут — аж 4
В общем, ситуация с заинтересованностью полностью симметрична.
S>Ну падумаешь подогнали фреймворк под тест S>Всё равно ведь малаццы. TCP-E обещают (которым никто кроме МС не меряется потому как там условия пореальней чем в TCP-C).
Мы уже почти передумали про TPC-E — действительно, чтоб его сделать, надо основательно попотеть.
С другой стороны, пока очень вероятно, что нас поддержат Telerik (OpenAccess) & Mindscape (Lightspeed). Общаюсь с ними уже пару дней, и все пока позитивно. Обид на нас нет, оптимизируют свои тесты и даже предлагают помощь Как только появится какая-то окончательная договоренность, сразу напишу.
А если такая поддержка будет — думаю, с выбором приемлемого для публики теста проблем не будет вообще.
Про Oren-а Eini: не знаю, в курсе ли вы, но Oren Eini = Ayende @ Rahien (nickname). Надеюсь, теперь понятно, почему именно в этом блоге были такие дебаты Это самый известный блог NH.
Здравствуйте, alexyakunin, Вы писали:
A>Про Oren-а Eini: не знаю, в курсе ли вы, но Oren Eini = Ayende @ Rahien (nickname). Надеюсь, теперь понятно, почему именно в этом блоге были такие дебаты Это самый известный блог NH.
В курсе, конечно. Потому и интересно было посмотреть на схватку в комментариях
Мое мнение остается прежним -- вы друг друга не поняли. Это круто, конечно, что у вас материализация enity происходит в 4 раза быстрее, но каков профит от этого для бизнес-приложения в целом?
О, еще вопрос -- планируется ли real-world bench? Я понимаю, что Oren и про них много интересного сказал , но было бы странно, если бы эти его слова для вас значили больше, чем предыдущие
Здравствуйте, alexyakunin, Вы писали:
M>>Хм, не знаю, откуда вы эту мораль вытащили. Ждем пруфлинк на цитаты про то, что сделать корректный показательный бенчмарк вообще невозможно. Тут он говорит только о трудностях, связанных с посторением таких бенчмарков, не более -- в связи с тем, что у каждого ORM существует оптимальный сценарий, есть нечаянный (или намеренный) риск сделать так, что остальные отстанут, и это будет нечестно.
A>Я даже искать не буду, возму то, что есть: A>"The only way to really create a benchmark is to create a full blown application with several backend implementations. That is still a bad idea, as there are still plenty of ways to cheat. All you have to do is to look at the PetShop issues from 2002/3 to figure that one out."
A>И для вас выделю суть: A>"The _only_ way to _really create_ a benchmark is ... _That is still a bad idea_, as there are still plenty of ways to cheat. All you have to do is to look at ... to figure that one out."
Простите, не увидел. Не стану повторяться, прочтите, будьте добры, мое предыдущее сообщение. Он не говорит о невозможности, он говорит об общей сложности.
A>Среди этих несколько человек есть Oren и Fabio (разработчики NH), которые напрямую заинтересованы в результате теста. Предлагаю вам всерьез подумать, чего бы они сказали, если бы NH там была на высоте, или просто #1. Я думаю, пост был бы один, и совершенно другого характера. А тут — аж 4
Прошу прощения; полагаю, вы берете на себя слишком много. Сослагательное наклонение не заменит тесты и не может судить мерилом правильности. Остыньте
A>В общем, ситуация с заинтересованностью полностью симметрична.
Согласен полностью Предлагаю убрать и их тесты, раз уж вы убрали свои -- это единственная оставшаяся несимметричность
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, meowth, Вы писали:
M>>Не должно быть так -- по душе. Должно быть -- объективны или нет. Если несколько человек -- Brion, Rahien, Maulo говорят, что что-то не так -- это значит, что действительно что-что не так.
IT>А я говорю, что всё так. Это значит, что всё действительно так?
Не знаю Вы какое отношение имете к тестам и к тому, что они тестируют?
IT>Любой тест показывает именно то, что он тестирует и не важно устраивают эти результаты проигравших или нет. Лично для меня все тесты вполне адекватны и весьма показательны. Если NH тормозит на материализации, то это сразу видно и мне всё равно какой вклад этот тормоз будет вносить в приложение.
А для меня -- нет Но я понял политику, ага. Отвечу так: в деревне VillaRiba посмотрели на примеры real-world приложений, заценили тул, выбрали оптимальный, и давно сдали проект. А в деревне Villabadjo продолжают самозабвенно надрач%вать на статсы материализации.
В смысле, если бы были жалобы на низкую производительность, ими бы занимались в первую очередь -- проекту не год и не два.
P.S. Сколько приложений бегают на DataObjects? А Hibernate тем временем -- корпоративный стандарт.
IT>Тормоза видны? Видны. Значит идите и работайте или признайте, что да, мы тормозим, но считаем это вполне приемлемым для себя и для наших пользователей.
Так они и сказали: да, мы тормозим, но это by design. Есть пост об этом. Разработчики считают это ходом, вы -- кривым архитектурным решением. Ни мое, ни ваше мнение впрочем не повлияет на разработчиков
IT>Если же у ребят есть свои сценарии, где их ORM показывает себя с лучшей стороны, то давайте добавим эти тесты и посмотрим результаты. Если же они способны лишь на дискредитацию тестов, то как минимум это не спортивно.
Они не собираются _дискредитировать_ тесты. Они лишь говорят о том, что судить по результатам _этих_ тестов о применимости (и неприменимости) того же NHibernate в реальных приложениях -- неверно.
IT>Тест, в качестве одного большого приложения ничего не даст по той простой причине, что охватить одним приложением множество сценариев, в котором каждый ORM сможет себя проявить просто нереально. Это будет столько разных архитектур, сколько ORM. И зависеть тесты будут не от возможностей ORM, а от квалификации разработчиков. Например, если взять тест, где определённые данные из справочника будут выводится на веб-страничку, то победит не лучшая ORM, а тот, кто додумается включить кешь страницы и т.п.
Это и сказал Ayende. С точность до буквы, только не раскрыл.
Здравствуйте, alexyakunin, Вы писали:
A>С другой стороны, как раз сейчас мы приделываем к нему local cache в нескольких ипостасиях ... у нас уже есть своя собственная БД в памяти ... Пока же мы делаем обычный DisconnectedState.
Согласен. Disconnected state — маст хэв, в отлисие от in-memory db. Сценарии использования local cache очень отличаются от uow. Последний рулит там где нет необходимости майнтайнить сущности. Как понадобится — всё печально.
У кэша обычный режим: залил, отсоединился, работаем-работаем-работаем, синхронизировались и опять рассоединились, работаем...
Сваять простейший кэш с хранением по столбцам — дело дня (делал). Если хранить в столбцах не только список значений, но и что-то типа Dictionary<T,List<int>> — индексы значений, то тру-индексы особо не нужны.
Объясняю почему:
получение индекса произвольного значения важно для проверки существования и получения родителей, детей. Этого достаточно для самого хранилища, т.к. запросы к нему выполняются относительно редко, куда чаще требуются биндинг к отфильтрованному списку (аля DataView). Тут от индексов нет никакой пользы, т.к. список просто ловит события родительской таблицы и фильтрует строки по поставленному условию. С сортировкой тоже нет особых проблем — используем SortedDictionary и всё.
Поэтому я слегка сомневаюсь что тру-индексы/оптимизатор/запросы будут полезны для local cache. Обычно куда важнее другие фичи (например, undo/redo по всем изменениям).
P.S. вполне возможно что под local cache мы понимаем разные вещи. Я рассматриваю кэш как автономное хранилище данных, заведённое для того чтобы централизованно ими управлять/хранить состояние приложения.
Прошу прощения, но поступаю как и обещал -- завязываю дискуссию. На прощание вот что:
IT>Сочувствующий. Понятно.
Ага. Это хорошо.
IT>Да он для многих типов сценариев не подходит. Вы бы лучше там подумали и предложили свои сценарии, это было бы гораздо интереснее и продуктивнее, чем кидаться какашками в ORMBattle и теоретизировать на тему жизни, встречаемости и применимости.
Видимо, у меня были другие сценарии, на которых он подходил.
M>>Кстати, чего это им стреляться -- Nhibenate вышел неплохим середнячком по тестам. IT>Ну да
Ну вот и ок)
IT>Но-но-но, это уже начинает тянуть на клевету. Давай не будем так низко опускаться. Твой NH всего лишь тул, как можно ненавидеть тул, например, как можно ненавидеть пассатижи? Ненавидеть можно тех кто его использует, но не понятно за что. Этих людей нужно не ненавидеть, а пожалеть, сирых и убогих, с искалеченной хайбернейтом судьбой.
Не не, никакой клеветы. Если так показалось, то сорри за это, однозначно ошибочно.
M>Простите, не увидел. Не стану повторяться, прочтите, будьте добры, мое предыдущее сообщение. Он не говорит о невозможности, он говорит об общей сложности.
Прочел: "Хм, не знаю, откуда вы эту мораль вытащили. Ждем пруфлинк на цитаты про то, что сделать корректный показательный бенчмарк вообще невозможно."
Вообще, я очень внимательно все читаю. И не люблю, когда мне врут в лицо в вежливой форме
M>Прошу прощения; полагаю, вы берете на себя слишком много. Сослагательное наклонение не заменит тесты и не может судить мерилом правильности. Остыньте
А я и не дергаюсь Про тесты я ничего не понял.
A>>В общем, ситуация с заинтересованностью полностью симметрична. M>Согласен полностью Предлагаю убрать и их тесты, раз уж вы убрали свои -- это единственная оставшаяся несимметричность
Заметьте, я не говорил, что надо устранить все, что несимментрично. Это сказали вы. Убирать тесты NH только потому, что он там отстал — сущая глупость.
Давайте я вам лучше вместо ответа часть сегодняшнего пиьмамне процитирую:
"Sure, there have been mistakes on both side, but I definitely agree with the necessity of having a good and non-biased ORM testing site. Can you even imagine buying a video card, CPU, or HDD without having a bunch of benchmarks to look at?! Imagine the reaction if AMD/ATI or NVIDIA would ask to be removed from a benchmarking test. They'd be laughed out of the room!"
M>>Мне все равно, что говорят вам товарищи. It works for me, что поделать IT>О! Вот с этого и надо было начинать. Надо сразу говорить, тормоза меня вполне устраивают, а не рассуждать о синтетичности и встречаемости в жизни тех или иных сценариев.
Мда... Поддерживаю полностью. Если вам все равно — какой смысл критиковать тесты, которые вы даже не смотрели?
IT>Смотрю, материализация отличается в 20 раз. 20 РАЗ! Это — позор!
Я тоже так считаю. Это говорит только о том, что NH никогда всерьез не профайлили.
M>>EF и NHibernate примерно одинаковы по производительности (причем NHIbernate, в основном, впереди). Единственная "засада" -- с материализацией сущностей на крупных объемах данных в одной сессии работой с БД, да. Но это вот почему: сессии NHibernate не расчитаны на batch processing -- они OLTP, небольшими порциями: create — process — discard. А в тестах происходит именно это -- многотысячи объектов грузятся в одну и ту же ISession. Поэтому я не спорю -- NHIbernate не слишком сильно подходит для такого типа сценариев.
IT>Да он для многих типов сценариев не подходит. Вы бы лучше там подумали и предложили свои сценарии, это было бы гораздо интереснее и продуктивнее, чем кидаться какашками в ORMBattle и теоретизировать на тему жизни, встречаемости и применимости.
Давайте отметим вот что: EF в этом смысле очень похожа на NH, и она более, чем подходит для тех же сценариев. Посему в данном случае by design = by bad design.
M>>Абсолютно согласен. И еще раз согласен. Трижды согласен, если хотите. Но эти тесты -- они не для разработчика, понимаете. Они -- для того, кто будет определять стратегию проекта, для менеджера, если так угодно. А он не будет разбираться -- он просто вставит цифры в презентацию и скажет: "Ё-ма-на, DataObject.NET, однозначно!".
Основательный бред
IT>Эти тесты прежде всего для разработчиков ORM. Не нужно учить людей как им правильно жить, не нужно им навязывать своё мнение, которое по сути прикрывает промахи в архитектуре инструмента и лень. Нужно сесть и заняться оптимизацией производительности инструмента, тогда таким разработчикам будет почёт и уважуха. Кстати, разработчики других тулов так и сделали. Нытьё слышится только от команды NH. Стыдно должно быть.
Согласен. Мы сейчас общаемся с коммандами Telerik & Mindscape, и все очень и очень гладко пока, хотя они намного более заинтересованы в результатах теста — у них-то продукты полностью коммерческие. Могу добавить, что никто из них гневных писем нам не писал. Скорее, наоборот. Хотя пока не будем забегать вперед — как только мы более-менее договоримся (я хочу довести все до появления чего-то вроде ORM vendor group, члены которой могут в равной степени влиять на тесты & ORMBattle.NET), я думаю, они сами изложат свое мнение.
В любом случае, их реакция — абсолютно адекватна. Telerik скачал все тесты еще до оффиц. запуска проекта (читают мой блог, видимо ), и ни слова не сказал. Но то, что делали Франс и Орен — просто аут, на мой взгляд. Я еще понимаю, если бы мы отказывались изменять их тесты там, или ошибки править. Но ведь все было в точности наоборот.
"Нас нельзя сравнивать! Мы против, т.к. это вредит нашей репутации!" — задумайтесь над этим бредом.
IT>Как можно скомпилировать и погонять ваши тесты? Всё вроде скачал, но собрать невозможно, т.к. всё завязано на какие-то библиотеки, которые негде взять
Напишите мне на alex@x-tensive.com, я вышлю Lib.rar + дам доступ к репозиторию на Google Code (надо брать последнюю версию).
Lib мы пока выложить не можем — выложим, как только окончательно договоримся с Telerik и т.п.
А инструкция появится в репозитории завтра-послезавтра.
Здравствуйте, alexyakunin, Вы писали:
A>В любом случае, их реакция — абсолютно адекватна. Telerik скачал все тесты еще до оффиц. запуска проекта (читают мой блог, видимо ), и ни слова не сказал.
Кстати, как собрать ваши тесты? Там у вас даже базовые вещи интенсивно завязаны на Xtensive, а это как я понимаю коммерческая либа.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexyakunin, Вы писали:
M>>Простите, не увидел. Не стану повторяться, прочтите, будьте добры, мое предыдущее сообщение. Он не говорит о невозможности, он говорит об общей сложности.
A>Прочел: "Хм, не знаю, откуда вы эту мораль вытащили. Ждем пруфлинк на цитаты про то, что сделать корректный показательный бенчмарк вообще невозможно." A>Вообще, я очень внимательно все читаю. И не люблю, когда мне врут в лицо в вежливой форме
Меньше всего хотелось бы обсуждать, что вы любите, а что нет, уж извините. Блин, наверное, мы на разных языках думаем. Я увидел там (в цитате Орена) только сомнение в том, что а) такие тесты легко построить б) такие тесты можно однозначно считать объективными. "Такие тесты" -- это в смысле, full-blown application. Если вы видите там что-то другое -- видимо, нам друг друга не понять до конца Предлагаю вообще прекратить спорить на эту тему. Спасибо.
A>>>В общем, ситуация с заинтересованностью полностью симметрична. M>>Согласен полностью Предлагаю убрать и их тесты, раз уж вы убрали свои -- это единственная оставшаяся несимметричность A>Заметьте, я не говорил, что надо устранить все, что несимментрично. Это сказали вы. Убирать тесты NH только потому, что он там отстал — сущая глупость.
Эй, эта была шутка
A>Фанатики NH, вероятно, этого не понимают.
Все может быть.
Ладно, если предметно: на месте Орена я бы поср%лся, конечно (будем считать -- ради приличия) на тему тестов, но потом все-таки подумал. Но зная его -- а вернее, то, что он упрямей, чем афганский ишак -- нифига мы не увидим, до тех пор, пока кто-то из опенсорса не пришлет speed-up патчи С другой стороны, я думаю, он полагается на данные своего профайлера для NHibernate, и действительно уверен, что перфоманс там не есть stop-фактор.
Здравствуйте, meowth, Вы писали:
M>Ладно, если предметно: на месте Орена я бы поср%лся, конечно (будем считать -- ради приличия) на тему тестов, но потом все-таки подумал. Но зная его -- а вернее, то, что он упрямей, чем афганский ишак -- нифига мы не увидим, до тех пор, пока кто-то из опенсорса не пришлет speed-up патчи
Возьмись за это дело. Сделаешь доброе дело для всех и обессмертишь своё имя
Если нам не помогут, то мы тоже никого не пощадим.
IT>Как можно скомпилировать и погонять ваши тесты? Всё вроде скачал, но собрать невозможно, т.к. всё завязано на какие-то библиотеки, которые негде взять
IT>С другой стороны, учитывая сколько времени мы потратили на оптимизацию, вычищение боксинга и затрат на приведение типов, было бы стыдно проиграть.
Да, в этом смысле нам есть еще, чем заниматься Более того, есть места, в которых нам пока избавиться от боксинга будет крайне сложно.
IT>Код для Multiple CUD тестов был дописан уже по ходу, по мотивам тестов. Поэтому они и выглядят вроде как естественно, но работают быстро С другой стороны такая корова пригодится и самому, как-то раньше в голову не пришло. Спасибо создателям тестов за идею и возможность ещё раз взглянуть на API и полезные возможности библиотеки.
С другой стороны, фактически, он исп. в тестах NH, и тогда его и там нужно зарубать. В тестах для Subsonic мы подобное не стали юзать.
Поясню, почему мне это в данном случае не нравится: как, например, при его использовании с topological sort обстоят дела? Она производится автоматом, или должна быть сделана пользователем мануально? Я понимаю, что в данном тесте это роли не играет — но если такой API приводит к необходимость делать чего-то вручную в более сложных кейзах, не очень хорошо это.
В общем, если бы этот тест выглядел так же, как обычный, я бы подобных вопросов не задавал. С другой стороны, раз это дает преимущество + в общем-то не сильно осложняет жизнь, вероятно, именно его и надо использовать. Пока пусть будет так — послушаем, что другие скажут. Думаю, в таких случаях лучше просто ремарк делать на эту тему под результатами и в коде, но все же юзать такой вот API.
В любом случае, результат достоин всяческих похвал
IT>С Linq тестами пока не всё так гладно, там ещё много работы (вот если бы MS раньше созналась в том, что они бросают L2S), но думаю, что современем мы и тут не ударим в грязь лицом.
Здравствуйте, alexyakunin, Вы писали:
IT>>С другой стороны, учитывая сколько времени мы потратили на оптимизацию, вычищение боксинга и затрат на приведение типов, было бы стыдно проиграть.
A>Да, в этом смысле нам есть еще, чем заниматься Более того, есть места, в которых нам пока избавиться от боксинга будет крайне сложно.
На самом деле для Linq с поддержкой Expression можно выжать почти всё. В случае с Linq нам известна структура data source, а это значит, что на лету можно генерировать очень эффективные перекладывалки из датаридера в объекты.
A>Да, в этом отношении API для CUD multiple — весьма забавный Я, правда, сам все еще задаюсь вопросом, честно ли это — в см. у нас есть пунктик о special API: http://ormbattle.net/index.php/faqs/74-is-it-possible-to-use-a-specialized-api-instead-of-common-in-tests.html
Скажете так нельзя, переделаем на так как можно. Но тогда сразу появится претензия с SqlClient тестам. Получится, что они читят. Они и так читят на Single тестах, т.к. применение Prepare по логике теста весьма сомнительно, но сразу даёт 15-20% производительности, а у других даже команда на каждый вызов создаётся новая.
A>В любом случае, результат достоин всяческих похвал
Мы старались
IT>>С Linq тестами пока не всё так гладно, там ещё много работы (вот если бы MS раньше созналась в том, что они бросают L2S), но думаю, что современем мы и тут не ударим в грязь лицом.
A>Гм, а какое отношение L2S имеет к этому?
Изначально мы не планировали делать поддержку Linq вообще, т.к. думали, что команда L2S займётся поддержкой не только MSSQL, но и других серверов БД. Но т.к. они на это не решились, то я занялся этим делом.
Кстати, есть ещё один кандидат поучаствовать в соревновании — http://code.google.com/p/dblinq2007/ Они пытаются повторить функциональность L2S для нескольких серверов и даже вроде как на базе их кода сделана поддержка этого хозяйства в Mono (хотя могу и соврать).
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexyakunin, Вы писали:
IT>На самом деле для Linq с поддержкой Expression можно выжать почти всё. В случае с Linq нам известна структура data source, а это значит, что на лету можно генерировать очень эффективные перекладывалки из датаридера в объекты.
Да, все верно. У нас в этом отношении есть одно проблемное место, которое мы пока не можем закрыть: практически все работа с Tuples у нас происходит с боксингом. Можно сделать и без боксинга, но пока руки не доходят В оригинале я расчитывал на generic virtual methods, но очень быстро выяснилось, что они намного дороже боксинга: http://tips.x-tensive.com/2008/10/method-call-performance.html
Решения, понятно, есть, но делать их пока нет времени Надеюсь, к концу года доберемся
IT>Скажете так нельзя, переделаем на так как можно. Но тогда сразу появится претензия с SqlClient тестам. Получится, что они читят. Они и так читят на Single тестах, т.к. применение Prepare по логике теста весьма сомнительно, но сразу даёт 15-20% производительности, а у других даже команда на каждый вызов создаётся новая.
Думаю, мой голос тут роли играть вообще не должен. Подождем остальных.
IT>Изначально мы не планировали делать поддержку Linq вообще, т.к. думали, что команда L2S займётся поддержкой не только MSSQL, но и других серверов БД. Но т.к. они на это не решились, то я занялся этим делом.
А, ясно
Кстати, а текущие-то тесты компилируются? Если да — думаю, вам стоит из закомиттить. Подозреваю, как минимум NH забороть более, чем реально.
IT>Кстати, есть ещё один кандидат поучаствовать в соревновании — http://code.google.com/p/dblinq2007/ Они пытаются повторить функциональность L2S для нескольких серверов и даже вроде как на базе их кода сделана поддержка этого хозяйства в Mono (хотя могу и соврать).
IT>Кстати, есть ещё один кандидат поучаствовать в соревновании — http://code.google.com/p/dblinq2007/ Они пытаются повторить функциональность L2S для нескольких серверов и даже вроде как на базе их кода сделана поддержка этого хозяйства в Mono (хотя могу и соврать).
Хмм... Последний апдейт — годовалой давности. Стоит ли общаться?
Здравствуйте, IT, Вы писали:
IT>Ага, спасибо. Мы порвали их всех!
IT>С другой стороны, учитывая сколько времени мы потратили на оптимизацию, вычищение боксинга и затрат на приведение типов, было бы стыдно проиграть.
IT>Код для Multiple CUD тестов был дописан уже по ходу, по мотивам тестов. Поэтому они и выглядят вроде как естественно, но работают быстро С другой стороны такая корова пригодится и самому, как-то раньше в голову не пришло. Спасибо создателям тестов за идею и возможность ещё раз взглянуть на API и полезные возможности библиотеки.
IT>С Linq тестами пока не всё так гладно, там ещё много работы (вот если бы MS раньше созналась в том, что они бросают L2S), но думаю, что современем мы и тут не ударим в грязь лицом.
Красиво. А можно посмотреть на код сего дела? Если нельзя выкладывать в паблик, то скинь плиз на мыло.
Здравствуйте, alexyakunin, Вы писали:
A>Хмм... Последний апдейт — годовалой давности. Стоит ли общаться?
Судя по логам репозитория последний коммит был пять минут назад.
Ещё раз кстати, есть ещё вот такое дело — http://www.codeplex.com/IQToolkit. Парень из MS и похоже работал в команде L2S (хотя я могу ошибаться). Делает что-то вроде универсальной парсилки LINQ выражений, но для MSSQL поддержка уже есть.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Код чего? Булкита? Так вот же — http://www.bltoolkit.net/download.htm. Всё паблик, лицензия MIT, можно даже заворачивать в упаковку и продавать
Не, код тестов. Где сам булкит мне рассказывать не нужно — я им уже много лет пользуюсь
M>В курсе, конечно. Потому и интересно было посмотреть на схватку в комментариях M>Мое мнение остается прежним -- вы друг друга не поняли. Это круто, конечно, что у вас материализация enity происходит в 4 раза быстрее, но каков профит от этого для бизнес-приложения в целом?
Посмотрите сейчас на новые тесты на paging. Они в основном зависят от Query & Materialization performance. Хотя не только, конечно. Оказалось, большинство участников реализует .Take неэффективно (с ROWNUMBER), и результат — налицо.
M>О, еще вопрос -- планируется ли real-world bench? Я понимаю, что Oren и про них много интересного сказал , но было бы странно, если бы эти его слова для вас значили больше, чем предыдущие
Здравствуйте, alexyakunin, Вы писали:
IT>>Кстати, есть ещё один кандидат поучаствовать в соревновании — http://code.google.com/p/dblinq2007/ Они пытаются повторить функциональность L2S для нескольких серверов и даже вроде как на базе их кода сделана поддержка этого хозяйства в Mono (хотя могу и соврать).
A>Хмм... Последний апдейт — годовалой давности. Стоит ли общаться?
Не стоит, пытался использовать в проекте .. много багов, многое просто не сделано.
Здравствуйте, achmed, Вы писали:
A>Не стоит, пытался использовать в проекте .. много багов, многое просто не сделано.
Это не удивительно. Я как-то глянул их код, там классический закат солнца в ручную. Такие задачи так не решаются. Тем не менее, кому-то это может быть интересно, тем болеее, если они идут в Моно.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexyakunin, Вы писали:
A>Посмотрите сейчас на новые тесты на paging. Они в основном зависят от Query & Materialization performance. Хотя не только, конечно. Оказалось, большинство участников реализует .Take неэффективно (с ROWNUMBER), и результат — налицо.
Кстати, а как можно сравнить эффективность генерируемого SQL? Это ведь тоже важный аспект. Материализация — это нагрузка на клиета, а вот SQL — это уже удар по серверу БД.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, AlexGX, Вы писали:
AGX>Добрый день.
AGX>Недавно на сайте ormbattle.net появилось сравнение производительности популярных .NET ORM. В частности, присутствуют NHibernate, Entity Framework, Open Access и другие. Как думаете, насколько приведенные результаты адекватны?
Я что-то не пойму, а где "знаменитый" LLBLGen Pro ?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alexyakunin, Вы писали:
IT>Кстати, а как можно сравнить эффективность генерируемого SQL? Это ведь тоже важный аспект.
Как минимум возможность указывать хинты в запросах NOLOCK, NOWAIT и пр.
В NH реализовано. IT>Материализация — это нагрузка на клиета, а вот SQL — это уже удар по серверу БД.
Здравствуйте, achmed, Вы писали:
IT>>Кстати, а как можно сравнить эффективность генерируемого SQL? Это ведь тоже важный аспект. A>Как минимум возможность указывать хинты в запросах NOLOCK, NOWAIT и пр. A>В NH реализовано.
Я не об этом. Например, один ORM для Take(10) генерирует TOP 10, а другой вариант, построенный на ROW_NUMBER(), один для string.CompareTo — сложный CASE, а другой — Field > @param, один — вычищает подзапросы по максимуму, а другой создаёт их по делу и без дела.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Я не об этом. Например, один ORM для Take(10) генерирует TOP 10, а другой вариант, построенный на ROW_NUMBER(), один для string.CompareTo — сложный CASE, а другой — Field > @param, один — вычищает подзапросы по максимуму, а другой создаёт их по делу и без дела.
ИМХО это более интересный показатель нежели скорость материализации.
Только автоматизировать такое сравнение очень сложно .
Здравствуйте, achmed, Вы писали:
IT>>Я не об этом. Например, один ORM для Take(10) генерирует TOP 10, а другой вариант, построенный на ROW_NUMBER(), один для string.CompareTo — сложный CASE, а другой — Field > @param, один — вычищает подзапросы по максимуму, а другой создаёт их по делу и без дела.
A>ИМХО это более интересный показатель нежели скорость материализации.
Они обе интересны. Низкая скорость материализации способна легко убить нагруженный сервер приложений.
A>Только автоматизировать такое сравнение очень сложно .
Нужно, чтобы провайдеры хоть каким-то способом умели отдавать SQL и параметры.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, achmed, Вы писали:
IT>>>Я не об этом. Например, один ORM для Take(10) генерирует TOP 10, а другой вариант, построенный на ROW_NUMBER(), один для string.CompareTo — сложный CASE, а другой — Field > @param, один — вычищает подзапросы по максимуму, а другой создаёт их по делу и без дела.
A>>ИМХО это более интересный показатель нежели скорость материализации.
IT>Они обе интересны. Низкая скорость материализации способна легко убить нагруженный сервер приложений.
Может, однако чаще проблемы с производительность возникают при обращению к SQL.
A>>Только автоматизировать такое сравнение очень сложно .
IT>Нужно, чтобы провайдеры хоть каким-то способом умели отдавать SQL и параметры.с испр
Можно подойти сбоку, например, с помощью profiler api перехватывать вызовы классов ADO.NET.
Мне бОльшая сложность видится в автоматическом анализе кода SQL.
Здравствуйте, IT, Вы писали:
A>>Не стоит, пытался использовать в проекте .. много багов, многое просто не сделано.
IT>Это не удивительно. Я как-то глянул их код, там классический закат солнца в ручную. Такие задачи так не решаются. Тем не менее, кому-то это может быть интересно, тем болеее, если они идут в Моно.
Не, ну почему? Если ночь полярная, а бригада ударная, то...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
Вы какое отношение имете к тестам и к тому, что они тестируют?
А почему тогда EF имеет вполне приличную производительность при схожей функциональности?
Ненавидеть можно тех кто его использует, но не понятно за что. Этих людей нужно не ненавидеть, а пожалеть, сирых и убогих, с искалеченной хайбернейтом судьбой.
Предлагаю вообще прекратить спорить на эту тему. Спасибо.
