Здравствуйте, 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.
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
В оригинале я расчитывал на generic virtual methods, но очень быстро выяснилось, что они намного дороже боксинга: http://tips.x-tensive.com/2008/10/method-call-performance.html
Если нам не помогут, то мы тоже никого не пощадим.
.
