Замена orm

Ну, т.е. пригодился-таки SQL, cформированный «ручками»? )))

Ну да, но можно было и без него в принципе. Я сперва хотел сделать выборку через подзапрос, а в hql так нельзя. В итоге сделал тупо на sql, потом подзапрос убрал, и так всё и оставил.

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

Да, но там не настолько всё сложно. Совсем тупая оптимизация дала нохерялд процентов прироста. Объекты по id я также дёргаю через hibernate из этого хешмапа, т.к. просто в лом было писать маппинг. Всунул просто костыль в бок и всё завертелось.

Скорее всего, твой предшественник вообще не заморачивался над тем, как извлекаются данные из оракловой базы - он просто по ORM-ной наивности считал, что данные сразу мгновенно в оперативной памяти оказываются )

Да я вообще не знаю, как он ночью нормально спать мог, зная, что у него что-то там по 5 часов считается.

А теперь можешь пытаться доказать, что оно правильно считает :)

Откуда ты знаешь чем я занят? Ты следишь за мной?

Бухло и жопа — это твои излюбленные темы, уебан. Как-то не ново, где-то я это уже читал...))) методичка одна что ли?) я бы тебе, дурилка картонная, ответил по пунктам, но ты пока туповат и недостоин. Соберись с мыслями и напряги головку, которая выше пояса ))

Совсем тупая оптимизация дала нохерялд процентов прироста.

Добро пожаловать в реальный мир. В нём нужно не знать сотни ключей gc или менять один orm на другой, а просто не делать сетевых вызовов в цикле.

Да кривой этот гибернейт. Вот как в нём сделать вложенную коллекцию типа HashMap<Key, List<Value>> без танцев с промежуточными сущностями?