[hibernate-dev] Memory consumption

[Steve Ebersole]

Sanne, the "problem" discussed here is not the size of the statements 
nor the number of rows returned.  Its the number of statements 
generated and maintained in memory by Hibernate.

Thats being said, I wholeheartedly agree about people trying extremes 
as the solution to a problem.  An extreme is rarely ever the best 
solution.  In your example, I'd have opted for subselect fetching 
however (or maybe even batch fetching) over select fetching.


On Thu 17 May 2012 02:12:54 PM CDT, Sanne Grinovero wrote:
> 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

--
steve at hibernate.org
http://hibernate.org