[hibernate-dev] SingleTableEntityPersister memory footprint in 5.3

[Steve Ebersole]

<quote>
>> Deferring initialization of these batch loaders is one option, but that
just really delays the memory consumption.  Personally, if it were my app
I'd rather that sizing be done up front rather than over the course of the
next few hours or weeks as the system continues to run.
</quote>

Not sure how that is advocating that we delay the generation ;)

Anyway, that email thread is what led me to add the different batch modes.
That helps with the memory consumption (I think - I was waiting on someone
to test it).  Have you tried one of the alternative batch modes?  I think
DYNAMIC is the only one that will improve memory usage, however it incurs
the overhead of calculating the SQL each and every time.

I have always had the idea to come back and delay the creation of these.
IMO we could calculate the most likely used Loaders up-front
(LockMode.NONE, LockMode.READ) and delay the more less-used ones.  I think
this is part of the solution.

I think the bigger solution is along the lines of what Guillaume is
planning on looking at.  In fact this is one of the design aspects of 6.0.
Loader is designed to bind the SQL and the "load plan" into one
representation.  The problem here is that it is designed to do this by
doing both tasks internally - it templates building the SQL via its
JoinWalkers, which also builds the "load plan".  So both happen at the same
time as part of the  same process.  The real solution is to break this up
so that generation of the SQL and determination of the "load plan" can be
separate operations - namely so that we can share the "load plan" graph
with all of the nested loaders for a given batch loader (sharing the load
plan across all batch loaders for a given entity is not feasible - some
different fetch grapghs.

Anyway, like I said - this is one of the design goals with 6.0 and is
actually already in place there.

I think ultimately a combination of delayed (and then cached) generation of
these <things responsible for loading> and separately creatable and
passable "load plans" (especially in combination with batch strategies) is
the ultimate solution.  I'm just not sure how feasible the "separately
creatable and passable load plans" portion is in 5.x.  Hopefully Guillaume
has luck solving that one.



On Tue, May 8, 2018 at 7:27 AM Andrej Golovnin <andrej.golovnin at gmail.com>
wrote:

> Hi Sanne,
>
> > sounds great. Do you plan to contribute your updated patch version?
>
> I don't think it is needed. I'm sure Guillaume will provide a good
> solution. And if not, then I will still have the best Hibernate
> version ever. :-) (OK, I will have in any case the best Hibernate
> version ever because I have more patches. But this is another story.
> :-) )
>
> Best regards,
> Andrej Golovnin
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>