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 <golov...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
