Здравствуйте, Blazkowicz, Вы писали:

B>На одном форуме проскакивало: переписали проект с JDBC на Hibernate — стало в 10 раз медленнее. Вывод — Hibernate в 10 раз медленнее JDBC. Вот и тут похожая ситуация.

В 10 раз это преуменьшение. Я бы сказал в 1000 раз Вот я выложил результат запуска профайлера для чтения 1'000 объектов. JDBC calls 20мс из 5,5 тыс. мс. Подавляющее большинство времени занимает работа самого фреймворка. Самое интересное, что при росте числа объектов, обрабатываемых в одной сессии тормоза растут далеко не линейно! При том это не только моё мнение. Вот свежий пример сумнящегося в масштабируемости хибернейта. А вот бяка, которая вылазит при наличии L2-кеша и желания вставить/изменить много объектов. В результате выходит, что пока ты в работаешь с одним объектом, всё хорошо. А если тебе нужно массово обработать объекты, то с Хибом добро пожаловать в АдЪ Попытки исправить всё в лоб — больше загружать через lazy-load могут очень очень ухудшить положение. Любые попытки распаралелить обработку — это либо по сессии на тред и кардинальный рост занятой памяти плюс накладные расходы на вычитку объектов в разных тредах, либо попытка всё вычитать один раз и обрабатывать в разных тредах, тогда добро пожаловать в поисх ошибок связанных с ленивыми прокси. В этом случае LazyInitializationException — это большая удача, а всё может стать хитрее.

Судя по наличию такой проблемы у соседей по палате, э-э т.е. платформе

Автор: Sinix
Дата: 11.12.07

(цитата: "жалкие полтыщи /.../ строк должны загружаться по три-пять секунд") дело тут не только в Хибернейте. Как я помню, то при использовании ORM в Smalltalk (Glorp for VW) данные читались медленно (St всё таки ), но быстрее чем сейчас через Хибернейт (Это на PII-350 с 64Mb тогда против Core Duo 6600 с 2Гб сейчас)! Могу предположить, что дело в стоимости рефлексии (которую почему то считают ооочень быстрой в Java).

В итоге, я вполне допускаю, что готовить я Хибер просто не умею, но продукт, который призван что-то облегчать должен быть проще в готовке.