[hibernate-dev] Memory consumption
Sanne Grinovero
sanne at hibernate.org
Thu May 17 15:12:54 EDT 2012
On 17 May 2012 17:53, Andrej Golovnin <golovnin at gmx.net> wrote:
> Hi Steve,
>
>> 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.
>
> The question is, if you really need all LockModes for an entity. I personally doubt it.
+1
It's definitely better to pre-create them rather than on-the-fly when
they are needed, but it's a likely bet that the majority will never be
used.
So the problem is with these very large SQL statements... on a related
anecdote, I have once seen a performance problem in which the culprit
was not the amount of statements sent to the database, nor the
database being too loaded, but the big sizes of the resultsets which
were shipped over the wire at each request: network bottleneck.
The problem was that developers had been too paranoid about the N+1
problem and were fetching everything with large JOIN FETCH statements,
which had exploded the cardinality of the ResultSet because of the
many redundancies (was actually a bit more complex, but you could
think of ManyToOne relations repeating the "the one" side over and
over).
The solution was to re-introduce N+1 :-) adding then second level
cache in strategical places.
This is to say, I wouldn't think only about the memory cost of the
bigger queries: the larger cost is likely their serialized form being
transmitted to the database.
Wouldn't it be very cool to define some queries as database functions?
-- Sanne
More information about the hibernate-dev
mailing list