[hibernate-dev] Memory consumption
steve at hibernate.org
Mon May 14 08:35:35 EDT 2012
> - 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.
Take 'temporaryIdTableDDL' as the perfect example. Hibernate cannot
know at start up (building the SessionFactory) that the application will
or will not use HQL updates/deletes against "multi-table structures"
that would therefore need access to 'temporaryIdTableDDL'?
And the problem with lazily generating them later is that that would
require keeping around the Configuration as part of the SessionFactory.
> - 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.
Hm, I had not thought of the UserType ServiceLoader approach. Thats
interesting, though not at all related to the "instance per usage"
If you want to get around having an instance-per-usage, use the
> - 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?
Configuration is not kept around by Hibernate itself once the
SessionFactory is built. Nor is SimpleValue. And as Hardy already
mentioned, that code is undergoing major changes already for 5.0.
steve at hibernate.org
More information about the hibernate-dev