[hibernate-dev] Memory consumption

[Sanne Grinovero]

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