[hibernate-dev] Memory consumption

[Emmanuel Bernard]

Btw for sure simpleValue should use an arrayList initialized to 1 by default as it's the most common case. 
We might even consider that an array would be better as the final holder even though there are no agreement in the team yet on the pro/con of arrays vs collections wrt ease of use, speed and memory consumption. 

On 13 mai 2012, at 11:07, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> 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
>> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev