Even using Lists we could trim those instances which are meant for long-term purpose; not being very familiar with the code in ORM/HEM I'm not sure which instances they are, but something among these lines, when inserted in the right places could provide an easy win:
https://github.com/Sanne/hibernate-orm/commit/3e9dadc6d92c58748a59539d851ed1eb12eb47e1 On 13 May 2012 10:26, Emmanuel Bernard <emman...@hibernate.org> wrote: > 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 <emman...@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 <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 > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
