[hibernate-dev] Memory consumption

[Emmanuel Bernard]

We deliberately chose to optimize hibernate ORM to be fast even if that means a bit more memory. 
We can try and avoid some objects here as there as you propose but I don't think that would be as beneficial as finding the real culprit between H3 and H4's memory consumption difference. 

On 12 mai 2012, at 22:48, Andrej Golovnin <golovnin at gmx.net> wrote:

> Hi Emmanuel,
> 
>> Andrej, I wonder if you could share with us these memory dumps privately so we could also analyze them.
> 
> I'm sorry but this is not possible. But I will give my best to find the root cause
> of this problem.
> 
> Here are my findings so far:
> 
> - In the memory dump with Hibernate 4 there are a lot of small
>  String objects. The content of these objects starts always with "$PlaceHolder$."
>  followed by a column name. This was introduced by HHH-4440.
>  Maybe interning of these strings would help. I will try it on monday.
> 
> - EntityPersisters contain SQL related strings which are never used.
>  For example: AbstractEntityPersister#temporaryIdTableDDL and 
>  #temporaryIdTableName. It exists also in Hibernate 3. I know for sure
>  that this #temporaryIdTableDDL is never used in our application
>  as the database user used by the application has no rights to create
>  temporary tables. Hibernate generates always all SQL statements
>  regardless whether they are required during the life time of an
>  application or not. Because Hibernate 3 shows the same behavior
>  in this case, I wouldn't touch it for now. But you should consider
>  it as possible improvement for the future.
> 
> - We make use of UserTypes. Although the specification of UserType 
>  requires custom implementations to be immutable, Hibernate creates
>  multiple instances, to be exactly for every occurrence of the Type annotation,
>  of the same implementation of UserType instead of reusing already
>  created instances. Hibernate 3 and 4 share here the behavior.
>  This could be also improved in the future. Personally I would prefer
>  to not use the Type annotation at all. Users of Hibernate may
>  publish they implementations of UserType by means of the ServiceLoader
>  from JDK 6.
> 
> - There are a lot of empty ArrayLists, HashMaps and HashSets which
>  are empty and have the default initial capacity (e.g. 10 by ArrayLists and 16
>  by HashMaps). But those objects exists also in the memory dump
>  with Hibernate 3. We may improve it when we change how collections
>  are created and filled in Hibernate code. I have done small changes to
>  org.hibernate.mapping.SimpleValue (see http://goo.gl/yKx5D). These
>  changes reduce the size of Configuration in my case from 16187776 bytes
>  to 15161672. The changes may look like an ugly hack and they have
>  higher resource costs (CPU, memory) during creation of SessionFactoryImpl.
>  But it should help to reduce memory if we use it wherever it makes sense.
>  What do you think?
> 
>  BTW, what is the purpose of CollectionHelper.EMPTY_LIST?
>  Why don't you use Collections.EMPTY_LIST?
> 
> That's all for now.
> 
> Best regards,
> Andrej Golovnin
>