Как LLBLGen Pro справляется с производительностью Nhibernate? - PullRequest
Новая
       22

Как LLBLGen Pro справляется с производительностью Nhibernate?

3 голосов
/ 04 декабря 2009

Я искал в Интернете все выше и ниже в поисках информации о производительности LLBLGen Pro. Ни один не найден. Просто хотел узнать, как работает LLBLGen Pro по сравнению с Nhibernate. Спасибо

Ответы [ 2 ]

6 голосов
/ 05 декабря 2009

На ваш вопрос практически невозможно ответить без контекста. Вопросы, которые я хотел бы задать в ответ, начинаются с:

  • Что за приложение? Data-ориентированный? Бизнес-логика ориентирована?
  • Сколько данных мы говорим?
  • О каких операциях с данными мы говорим? В основном читает? В основном пишет?

Как правило, LLBLGen работает очень хорошо. Мы использовали его в 10+ проектах (включая несколько проектов масштаба предприятия), где я работаю, и те немногие проблемы, которые мы наблюдали с производительностью, всегда были результатом неправильного понимания того, что делал код (есть кривая обучения) или плохо реализованная физическая модель (например, отсутствующие индексы).

Две структуры по-разному подходят к проблеме доступа к данным. Операции LLBLGen обычно переводятся в SQL, что довольно легко понять, если у вас сильный фон данных. NHibernate использует сессии и кэш для хранения данных в памяти, когда это возможно, для повышения производительности ( отказ от ответственности: я не эксперт NHibernate ). LLBLGen не поддерживает такого рода концепцию; вместо этого он работает в отключенном состоянии и сохраняет информацию об отслеживании изменений непосредственно в своих объектах сущности.

Суть в том, что подходы, используемые в фреймворках, очень разные, и трудно предсказать, какие из них будут работать лучше, не зная больше о том, что делает ваша система. В правильных руках любая инфраструктура может использоваться для разработки системы, в которой производительность доступа к данным не является основным узким местом производительности.

4 голосов
/ 04 декабря 2009

Изначально мы тестировали LLBLGen @ ORMBattle.NET, он был в 2 раза быстрее, чем NH при материализации; Время компиляции запросов LINQ было довольно хорошим (~ 4000 запросов / сек.), Но операции CUD были заметно медленнее, чем в NH (в LLBLGen нет пакетирования CUD).

Обе платформы должны быть относительно медленными в случае, когда вы имеете дело с большим количеством объектов в одном сеансе:

  • NH относительно медленный из-за своего материализационного трубопровода. Я не совсем уверен, почему, но, например, чтобы осуществить грязную проверку, NH должен где-то хранить клон любых материализованных объектов. Как минимум в два раза больше оперативной памяти ~ = как минимум в 2 раза медленнее.
  • LLBLGen использует относительно "толстые" сущности - кажется, они хранят поля в словарях. Очевидно, что это нехорошо с точки зрения производительности, поскольку потребление ОЗУ является одним из существенных факторов, влияющих на него.

См. в этом разделе часто задаваемых вопросов и Сводка набора тестов для более глубокого объяснения.

Короче говоря, LLBLGen Pro должен быть быстрее, чем NH при чтении, но медленнее при записи.

...