Здравствуйте, meowth, Вы писали:
M>Не должно быть так -- по душе. Должно быть -- объективны или нет. Если несколько человек -- Brion, Rahien, Maulo говорят, что что-то не так -- это значит, что действительно что-что не так.
А я говорю, что всё так. Это значит, что всё действительно так?
Любой тест показывает именно то, что он тестирует и не важно устраивают эти результаты проигравших или нет. Лично для меня все тесты вполне адекватны и весьма показательны. Если NH тормозит на материализации, то это сразу видно и мне всё равно какой вклад этот тормоз будет вносить в приложение. Тормоза видны? Видны. Значит идите и работайте или признайте, что да, мы тормозим, но считаем это вполне приемлемым для себя и для наших пользователей.
Если же у ребят есть свои сценарии, где их ORM показывает себя с лучшей стороны, то давайте добавим эти тесты и посмотрим результаты. Если же они способны лишь на дискредитацию тестов, то как минимум это не спортивно.
Тест, в качестве одного большого приложения ничего не даст по той простой причине, что охватить одним приложением множество сценариев, в котором каждый ORM сможет себя проявить просто нереально. Это будет столько разных архитектур, сколько ORM. И зависеть тесты будут не от возможностей ORM, а от квалификации разработчиков. Например, если взять тест, где определённые данные из справочника будут выводится на веб-страничку, то победит не лучшая ORM, а тот, кто додумается включить кешь страницы и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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. С точность до буквы, только не раскрыл.
Здравствуйте, 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 в реальных приложениях -- неверно.
А где в тестах речь о применимости? Тесты, как я уже сказал, показывают только то, что они тестируют. Выводы каждый делает сам и чем он при этом руководствуется его личное дело, будь это либо тесты, либо устные заверения разработчиков и сочувствующих.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, 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>Здравствуйте, 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>Ну я имел в виду 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. Стыдно должно быть.
Если нам не помогут, то мы тоже никого не пощадим.
Прошу прощения, но поступаю как и обещал -- завязываю дискуссию. На прощание вот что:
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 скачал все тесты еще до оффиц. запуска проекта (читают мой блог, видимо ), и ни слова не сказал. Но то, что делали Франс и Орен — просто аут, на мой взгляд. Я еще понимаю, если бы мы отказывались изменять их тесты там, или ошибки править. Но ведь все было в точности наоборот.
"Нас нельзя сравнивать! Мы против, т.к. это вредит нашей репутации!" — задумайтесь над этим бредом.
S>P.S. вполне возможно что под local cache мы понимаем разные вещи. Я рассматриваю кэш как автономное хранилище данных, заведённое для того чтобы централизованно ими управлять/хранить состояние приложения.
Вроде-бы и я так же. Просто похоже, что на его использование мы смотрим по-разному
Ну ладно, все равно его пока нет. Зато я сегодня написал большой пост на тему того, что уже почти есть: http://blog.dataobjects.net (DisconnectedState там более-менее описан).
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>Как можно скомпилировать и погонять ваши тесты? Всё вроде скачал, но собрать невозможно, т.к. всё завязано на какие-то библиотеки, которые негде взять
Здравствуйте, 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!
Здравствуйте, Andir, Вы писали:
A>Мои поздравления IT и всем участникам проекта BLToolkit
Ага, спасибо. Мы порвали их всех!
С другой стороны, учитывая сколько времени мы потратили на оптимизацию, вычищение боксинга и затрат на приведение типов, было бы стыдно проиграть.
Код для Multiple CUD тестов был дописан уже по ходу, по мотивам тестов. Поэтому они и выглядят вроде как естественно, но работают быстро С другой стороны такая корова пригодится и самому, как-то раньше в голову не пришло. Спасибо создателям тестов за идею и возможность ещё раз взглянуть на API и полезные возможности библиотеки.
С Linq тестами пока не всё так гладно, там ещё много работы (вот если бы MS раньше созналась в том, что они бросают L2S), но думаю, что современем мы и тут не ударим в грязь лицом.
Если нам не помогут, то мы тоже никого не пощадим.
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 (хотя могу и соврать).
Если нам не помогут, то мы тоже никого не пощадим.
Если нам не помогут, то мы тоже никого не пощадим.
Вы какое отношение имете к тестам и к тому, что они тестируют?
Но я понял политику, ага. Отвечу так: в деревне VillaRiba посмотрели на примеры real-world приложений, заценили тул, выбрали оптимальный, и давно сдали проект. А в деревне Villabadjo продолжают самозабвенно надрач%вать на статсы материализации. 
А почему тогда EF имеет вполне приличную производительность при схожей функциональности?
Ненавидеть можно тех кто его использует, но не понятно за что. Этих людей нужно не ненавидеть, а пожалеть, сирых и убогих, с искалеченной хайбернейтом судьбой.
Предлагаю вообще прекратить спорить на эту тему. Спасибо.
