Комментарии 50
Жаль, что автор не включил в обзор производительности сравнение с BLToolkit =)
По самой библиотеке — забавно, она в виде одного файла, можно включать куда угодно. Используется эмитинг. Мега-ORM она не заменит (да и использовать ее можно только с MS SQL Server), но для простых приложений — вполне можно. Также интересно поглядеть, как автор добивается высокой скорости маппинга.
По самой библиотеке — забавно, она в виде одного файла, можно включать куда угодно. Используется эмитинг. Мега-ORM она не заменит (да и использовать ее можно только с MS SQL Server), но для простых приложений — вполне можно. Также интересно поглядеть, как автор добивается высокой скорости маппинга.
Вставлю свои 5 копеек. Маппинг BLToolkita тормозной в сравнении с тем же emitmapper. Все хорошо при объемах в тысячи объектов но десятки и сотни тысяч начинались тормоза. В свое время отказались от него по этой причине. Плюс иногда выдавал совершенно дурные SQL запросы обрабатывая linq выражения. Может сейчас чтото и подделали, опыт был в 2009 — 2010 годах.
Оговорюсь — я имел ввиду маппинг просто объектов между собой а не с базы. в итоге остановились на .netTiers + emitmapper
Emit уже не модно rsdn.ru/forum/prj.rfd/3723299.flat.aspx
Автор BLToolkit'а где-то год назад переписал маппинг и на форуме RDSN ехидненько написал что-то вроде «Emit Mapper может идти тренироваться дальше».
Emit Mapper, кстати, в развитии остановился почему-то, больше года уже нет обновлений, хотя когда я эту библиотеку пробовал, уже была вполне законченным рабочим продуктом.
Emit Mapper, кстати, в развитии остановился почему-то, больше года уже нет обновлений, хотя когда я эту библиотеку пробовал, уже была вполне законченным рабочим продуктом.
Парень подготовил код под статью на хабре, а после этого забил на код. А на самом то деле он, по крайней мере на тот момент, был быстрее AutoMapper который щас очень популярен.
Хм, обратите внимание на эту статью habrahabr.ru/blogs/net/80793/.
EmitMapper сравним по скорости с ручным кодом, так что автор блтулкита либо научился выполнять MSIL код быстрее фрейморка либо заливает :).
Пользуюсь им везде где необходимо делать клонирование объектов. Раньше по незнанию пользовался XmlSerializer но это огромный провал по производительности.
EmitMapper сравним по скорости с ручным кодом, так что автор блтулкита либо научился выполнять MSIL код быстрее фрейморка либо заливает :).
Пользуюсь им везде где необходимо делать клонирование объектов. Раньше по незнанию пользовался XmlSerializer но это огромный провал по производительности.
Статья от января 2010 года.
Вот сообщение автора BLToolkit'а rsdn.ru/forum/prj.rfd/3723299.1.aspx, от марта 2010 г.
«Производительность, конечно, процентов на несколько хуже, чем рукописный код, но всякие ЕмитМаперы могут идти тренироваться дальше.»
Вот сообщение автора BLToolkit'а rsdn.ru/forum/prj.rfd/3723299.1.aspx, от марта 2010 г.
«Производительность, конечно, процентов на несколько хуже, чем рукописный код, но всякие ЕмитМаперы могут идти тренироваться дальше.»
Ну, EmitMapper, если и медленнее, чем BLT, то в таких ничтожных масштабах, что можно пренебречь.
хм… надо будет посмотреть :) даже прям попробовать!
Это сообщение из серии «сам себя не похвалишь, никто не похвалит», никаких тестов и подтверждающих фактов. Так что я бы не стал доверять таким категоричным высказываниям.
Писал не тот человек, который склонен заниматься пустой похвальбой. Цифр там действительно нет, но я уверен, что если провести испытания — его слова подтвердятся.
Это ваше субъективное мнение, а объективная картина может быть другой. Мне вот интересно, как вы можете быть уверены в цифрах, когда никаких испытаний не проводили? Вся ваша уверенность в технологии основана на косвенных знаниях о чертах характера отдельного человека.
Человек выше правильно сказал:
Тут нужны цифры и испытания, а не голословные утверждения, что вы уверены.
Человек выше правильно сказал:
EmitMapper сравним по скорости с ручным кодом, так что автор блтулкита либо научился выполнять MSIL код быстрее фрейморка либо заливает
Тут нужны цифры и испытания, а не голословные утверждения, что вы уверены.
Как бы вам попроще объяснить…
Я знаю, что есть люди, которые любят цепляться к словам, устраивать из этого троллинг и прочее. Или не устраивать, такое тоже бывает. Просто они невероятно дотошные.
Так вот, я знаю, что:
1. Сообщение, на которое я дал ссылку, написал автор и практически единственный коммитер проекта BLToolkit, и репутация у него на форуме RSDN очень высокая. Мы не совершим особо уж большой вольности, если допустим, что это человек, который знает возможности своего продукта и отвечает за свои слова.
2. Автор BLToolkit принимал непосредственное участие в тестах и обсуждении EmitMapper'а.
Теперь внимательно читаем фразу «Производительность, конечно, процентов на несколько хуже, чем рукописный код, но всякие ЕмитМаперы могут идти тренироваться дальше.» =) Разделим ее на две части.
«Производительность, конечно, процентов на несколько хуже, чем рукописный код» — тут, надеюсь, никаких противоречий и всяких когнитивных диссонансов? =) У эмитмаппера производительность на несколько процентов хуже, и у блтулкита несколько хуже. Ну, бывает =)
«но всякие ЕмитМаперы могут идти тренироваться дальше» — ну, я тоже уверен, что они могут идти тренироваться дальше. Всегда есть к чему стремиться =) Например, к тому, чтобы производительность была равна производительности рукописного кода.
Да, мое мнение субъективно =) как и всякое другое. И моя уверенность в технологии основана на личном применении. Это тоже субъективно, конечно =)
И если вам нужны цифры, просто проведите испытания, а не цепляйтесь от делать нефиг =)
Я знаю, что есть люди, которые любят цепляться к словам, устраивать из этого троллинг и прочее. Или не устраивать, такое тоже бывает. Просто они невероятно дотошные.
Так вот, я знаю, что:
1. Сообщение, на которое я дал ссылку, написал автор и практически единственный коммитер проекта BLToolkit, и репутация у него на форуме RSDN очень высокая. Мы не совершим особо уж большой вольности, если допустим, что это человек, который знает возможности своего продукта и отвечает за свои слова.
2. Автор BLToolkit принимал непосредственное участие в тестах и обсуждении EmitMapper'а.
Теперь внимательно читаем фразу «Производительность, конечно, процентов на несколько хуже, чем рукописный код, но всякие ЕмитМаперы могут идти тренироваться дальше.» =) Разделим ее на две части.
«Производительность, конечно, процентов на несколько хуже, чем рукописный код» — тут, надеюсь, никаких противоречий и всяких когнитивных диссонансов? =) У эмитмаппера производительность на несколько процентов хуже, и у блтулкита несколько хуже. Ну, бывает =)
«но всякие ЕмитМаперы могут идти тренироваться дальше» — ну, я тоже уверен, что они могут идти тренироваться дальше. Всегда есть к чему стремиться =) Например, к тому, чтобы производительность была равна производительности рукописного кода.
Да, мое мнение субъективно =) как и всякое другое. И моя уверенность в технологии основана на личном применении. Это тоже субъективно, конечно =)
И если вам нужны цифры, просто проведите испытания, а не цепляйтесь от делать нефиг =)
В данный момент пишу тест, уж больно заинтересовала свежая версия блтулкита. Как будут данные напишу сюды :)
Вобщем, ребята исправились, маппинг работает оч хорошо.
результат простого теста без глубокого мэппинга
Test for 1 items
BLToolkit time:00:00:00.0000013
EmitMapper time:00:00:00.0000018
Test for 10 items
BLToolkit time:00:00:00.0000022
EmitMapper time:00:00:00.0000031
Test for 100 items
BLToolkit time:00:00:00.0000144
EmitMapper time:00:00:00.0000208
Test for 1000 items
BLToolkit time:00:00:00.0001335
EmitMapper time:00:00:00.0001883
Test for 10000 items
BLToolkit time:00:00:00.0013372
EmitMapper time:00:00:00.0022130
Test for 100000 items
BLToolkit time:00:00:00.0135715
EmitMapper time:00:00:00.0192261
Test for 1000000 items
BLToolkit time:00:00:00.1399616
EmitMapper time:00:00:00.1949009
Test for 10000000 items
BLToolkit time:00:00:01.3721950
EmitMapper time:00:00:01.9405558
Test for 100000000 items
BLToolkit time:00:00:13.5768732
EmitMapper time:00:00:19.3475230
гдето раза в полтора скорость выше.
результат простого теста без глубокого мэппинга
Test for 1 items
BLToolkit time:00:00:00.0000013
EmitMapper time:00:00:00.0000018
Test for 10 items
BLToolkit time:00:00:00.0000022
EmitMapper time:00:00:00.0000031
Test for 100 items
BLToolkit time:00:00:00.0000144
EmitMapper time:00:00:00.0000208
Test for 1000 items
BLToolkit time:00:00:00.0001335
EmitMapper time:00:00:00.0001883
Test for 10000 items
BLToolkit time:00:00:00.0013372
EmitMapper time:00:00:00.0022130
Test for 100000 items
BLToolkit time:00:00:00.0135715
EmitMapper time:00:00:00.0192261
Test for 1000000 items
BLToolkit time:00:00:00.1399616
EmitMapper time:00:00:00.1949009
Test for 10000000 items
BLToolkit time:00:00:01.3721950
EmitMapper time:00:00:01.9405558
Test for 100000000 items
BLToolkit time:00:00:13.5768732
EmitMapper time:00:00:19.3475230
гдето раза в полтора скорость выше.
Спасибо, интересные результаты. На чем тестировали?
просто два класса с одинаковыми полями (типы ссылочные и по значению) ну и мапировал из одного в другой. скорость несравненно стала лучше. просто год назад я как раз на этом попался и перескочил на эмитмаппер.
сейчас поглядел как генерится sql из linq выражений — очень недурно, захотелось обратно на блтулкит переходить. уж больно код выходит простой, вобщем надо погонять на хитрых запросах и делать выводы.
сейчас поглядел как генерится sql из linq выражений — очень недурно, захотелось обратно на блтулкит переходить. уж больно код выходит простой, вобщем надо погонять на хитрых запросах и делать выводы.
Там в комментариях была такая ссылка, как раз от автора BLT, могу повторить здесь.
rsdn.ru/forum/dotnet/3658986.1.aspx
Дальше обсуждение тоже интересное.
После этой дискуссии маппер в BLT вроде бы подкрутили.
rsdn.ru/forum/prj.rfd/3669725.1.aspx
rsdn.ru/forum/dotnet/3658986.1.aspx
Дальше обсуждение тоже интересное.
После этой дискуссии маппер в BLT вроде бы подкрутили.
rsdn.ru/forum/prj.rfd/3669725.1.aspx
На тестах маппинга из БД, BLToolkit самый быстрый из всех широкодоступных мапперов. По крайней мере из тех, которые тестировались на ORMBattle.
ormeter.net/
Поскольку там тоже эмитт, как и в описываемой тулзе, подозреваю, что и результаты сравнимые. Другое дело, что инструмент из статьи заточен под конкретную задачу, а BLT довольно универсальный инструмент при всей своей относительной простоте…
Вообще BLT — это то, как должен был выглядеть Linq2SQL, если бы его не бросили. )
ormeter.net/
Поскольку там тоже эмитт, как и в описываемой тулзе, подозреваю, что и результаты сравнимые. Другое дело, что инструмент из статьи заточен под конкретную задачу, а BLT довольно универсальный инструмент при всей своей относительной простоте…
Вообще BLT — это то, как должен был выглядеть Linq2SQL, если бы его не бросили. )
StackOverflow был самым большим примеро использования Linq2SQL. Эх…
Просто шикарно.
Добавил в статью ссылку на блог Сэма
сайт StackOverflow — это чуть-ли не самый большой и посещаемый сайт в мире, построенный на .NET-платформe
Если .Net заменить на Asp.net MVC то пожалуй, а так еще есть как минимум:
www.myspace.com/ и www.plentyoffish.com/ которые более нагруженные.
Ключевая фишка не в том, что это ORM (по feature-set ей до того же NHibernate еще очень далеко — но тут сравнение неуместно, у них разные задачи). Я бы даже сказал, что это не ORM, а скорее некоторый простой Query+Mapper. Неудивительно, что он так быстр в своих задачах. ORM для таких сценариев не предназначены. Сила ORM — в OLTP-сценариях. А вот Batch-select'ы — зачастую слабое место ORM, и Dapper закрывает именно этот сценарий.
Что они сделали — это отделили мух от котлет. А именно — разделили часть, ответственную за запросы (в особенности batch-запросы), т. е. SELECT и часть, ответственную за манипуляцию данными (т. е. INSERT, UPDATE, DELETE).
Что они сделали — это отделили мух от котлет. А именно — разделили часть, ответственную за запросы (в особенности batch-запросы), т. е. SELECT и часть, ответственную за манипуляцию данными (т. е. INSERT, UPDATE, DELETE).
Сила ORM не в OLTP сценариях, а в том, что они (якобы) позволяют не думать об SQL, а оперировать объектами. В этом же и их слабость, так как за все приходится платить — в данном случае как скоростью, так и различного рода побочными эффектами.
«Сила ORM не в OLTP сценариях, а в том, что они (якобы) позволяют не думать об SQL, а оперировать объектами.»
Нет, в этом их _суть_ (в объектах). А использование оправдано именно для OLTP. Для массовой обработки данных, ETL и OLAP — ORM не подходят.
И думать об SQL нужно в любом случае, ибо если вы серьезно работали с ORM на .NET, то должны знать, что мало замаппить схему БД в Domain-модель, нужно еще определить Fetch-стратегии, стратегии кэширования и стратегии управления сессиями и транзакциями.
Скорость же и побочные эффекты — это уже вопрос реализации конкретных ORM.
Нет, в этом их _суть_ (в объектах). А использование оправдано именно для OLTP. Для массовой обработки данных, ETL и OLAP — ORM не подходят.
И думать об SQL нужно в любом случае, ибо если вы серьезно работали с ORM на .NET, то должны знать, что мало замаппить схему БД в Domain-модель, нужно еще определить Fetch-стратегии, стратегии кэширования и стратегии управления сессиями и транзакциями.
Скорость же и побочные эффекты — это уже вопрос реализации конкретных ORM.
Печальный момент в том, что теперь множество людей бросится это использовать, потому что «быстрее», хотя реально это важно для приложений размера SO. А в остальных случаях гораздо счастливее испоьзовать полноценный ORM.
В чем печаль? Если подходит по условиям задачи (например, только селекты) — можно использовать. Не подходит — не будут использовать. Это же не выбор между «модными» фреймворками.
А скорость много где важна. Попадаются клиенты, которые очень не любят, когда простые выборки данных (любых) делаются, на их взгляд, медленно,
А скорость много где важна. Попадаются клиенты, которые очень не любят, когда простые выборки данных (любых) делаются, на их взгляд, медленно,
Печаль в том случае, когда подходит по условиям сегодняшней задачи, а потом это расширять.
Что касается клиентов, то в хорошем приложении UI тормозить не должен в любом случае (для этого есть кеш и не только), а лезущих в код надо хотя бы пытаться перепрограммировать.
Что касается клиентов, то в хорошем приложении UI тормозить не должен в любом случае (для этого есть кеш и не только), а лезущих в код надо хотя бы пытаться перепрограммировать.
Согласен с вами. Ну, видимо, SO — достаточно высоконагруженный сайт, что им помимо кэша потребовалось поменять и сам механизм Read-части доступа к данным. Кстати, еще интересно, они упоминают, что не кэшируют контент для авторизованных пользователей, ибо у них 90% трафика — «неавторизованный» трафик с Гугла. Может оставшиеся 10% решили оптимизировать и таким вот способом тоже.
сайт StackOverflow — это чуть-ли не самый большой и посещаемый сайт в мире, построенный на .NET-платформe
Все-таки самый большой .Net сайт по посещаемости будет пожалуй msn.com — если я правильно помню, 9.5K запросов в секунду, что входит в пятерку самых нагруженных сервисов и больше чем на порядок превышает нагрузку SO. Там asp.net, mvc, вроде бы уже razor. Ну и куча своих фишек по оптимизации, конечно же, но все естественно win+net.
Все-таки самый большой .Net сайт по посещаемости будет пожалуй msn.com — если я правильно помню, 9.5K запросов в секунду, что входит в пятерку самых нагруженных сервисов и больше чем на порядок превышает нагрузку SO. Там asp.net, mvc, вроде бы уже razor. Ну и куча своих фишек по оптимизации, конечно же, но все естественно win+net.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У вас, похоже, не вызывается Enumerator для запросов LINQ-2-SQL и EF. Ведь данные нигде не используются, и он не вызывается неявно (соответственно, ничего не выбирается из базы — ибо нет команды на deferred execution).
Добавьте ".ToList()" к запросам (обратите внимание, что в оригинальных тестах использовался extension-метод ".First()", который сам по себе возвращает один экземпляр; если бы они написали ".Take(1)", то также нужно было бы добавлять ".ToList()").
А такая непропорциональная разница во времени пусть вас не смущает — движок БД сам производит самые разные оптимизации на разные запросы, плюс сами ORM по-разному оптимизируют и формируют их.
P.S. Самое забавное, то первый (исходный) тест отражает реальный сценарий использования, а простая выборка 100 записей — не дает никакого представления о том, как система будет вести себя в реальности.
Добавьте ".ToList()" к запросам (обратите внимание, что в оригинальных тестах использовался extension-метод ".First()", который сам по себе возвращает один экземпляр; если бы они написали ".Take(1)", то также нужно было бы добавлять ".ToList()").
А такая непропорциональная разница во времени пусть вас не смущает — движок БД сам производит самые разные оптимизации на разные запросы, плюс сами ORM по-разному оптимизируют и формируют их.
P.S. Самое забавное, то первый (исходный) тест отражает реальный сценарий использования, а простая выборка 100 записей — не дает никакого представления о том, как система будет вести себя в реальности.
В трекере уже попросили добавить также сравнение с bltoolkit. Стало очень интересно, сел прикручивать bltoolkit.
Протестировал с bltoolkit, на моей машине результаты оказались следующие:
Running 500 iterations that load up a post entity
— hand coded took 109ms
— Mapper Query took 118ms
— PetaPoco (Normal) took 130ms
— Dynamic Massive ORM Query took 132ms
— Dynamic Mapper Query took 136ms
— PetaPoco (Fast) took 136ms
— BLToolkit took 184ms
— Linq 2 SQL Compiled took 206ms
— SubSonic Coding Horror took 277ms
— NHibernate SQL took 325ms
— NHibernate HQL took 388ms
— Linq 2 SQL ExecuteQuery took 451ms
— Entity framework ExecuteStoreQuery took 1287ms
— Linq 2 SQL took 1347ms
— Entity framework took 2098ms
— SubSonic ActiveRecord.SingleOrDefault took 7980ms
Running 500 iterations that load up a post entity
— hand coded took 109ms
— Mapper Query took 118ms
— PetaPoco (Normal) took 130ms
— Dynamic Massive ORM Query took 132ms
— Dynamic Mapper Query took 136ms
— PetaPoco (Fast) took 136ms
— BLToolkit took 184ms
— Linq 2 SQL Compiled took 206ms
— SubSonic Coding Horror took 277ms
— NHibernate SQL took 325ms
— NHibernate HQL took 388ms
— Linq 2 SQL ExecuteQuery took 451ms
— Entity framework ExecuteStoreQuery took 1287ms
— Linq 2 SQL took 1347ms
— Entity framework took 2098ms
— SubSonic ActiveRecord.SingleOrDefault took 7980ms
Поправьте меня если я не прав, но насколько я понял, Dapper это просто query-mapper (как тут уже верно отметили) и он не позволяет работать через LINQ запросы к объектам (т.е. LINQ to SQL маппера нет).
А есть ли информация о сравнении операций выборки данных с LINQ to SQL mapping + result object mapping для разных библиотек?
А есть ли информация о сравнении операций выборки данных с LINQ to SQL mapping + result object mapping для разных библиотек?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Dapper.NET — «микро-ORM» на котором работает StackOverflow