Джим,
Чтобы получить наилучшие результаты при ответе на этот вопрос, вам необходимо провести собственное сравнение, поскольку ваши конкретные требования и сценарии доступа к данным, вероятно, повлияют на результаты любого такого тестирования производительности.
Тем не менее, мы используем LLBLGen для веб-приложений с высокой пропускной способностью, и производительность является исключительной.Мы обнаружили, что большая проблема заключается в самом дизайне приложения.Используя SQL Server Profiler, мы можем видеть (во время разработки), какие части приложения создают много попаданий в базу данных.Наибольшее наказание, которое мы обнаружили, было с загрузкой сетки и затем выполнением другой операции с базой данных события OnDataBinding / DataBound.Это создает огромный объем трафика к базе данных SQL Server, много операций чтения и большого количества операций обмена дисками.Мы очень хорошо справились, убедившись, что все данные в первом запросе получены, и сделали правильный выбор дизайна при создании набора данных / объединений / и т. Д.при создании приложения или его рефакторинге позже, когда мы обнаружим, что производительность низкая.
Затраты LLBLGen, по крайней мере, очень минимальны.Это быстро даже при создании огромного количества объектов.Намного, гораздо больший прирост производительности происходит, когда мы создаем запросы, которые порождают другие запросы (пример выше), и наши чтения из БД проходят через крышу.для ваших навыков и производительности.