[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-1258) startup time improvements

[Mike Quilleash (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=comments#action_25458 ] 

Mike Quilleash commented on HHH-1258:
-------------------------------------

Hi there.

I was pointed to this by someone on the Tomcat user list (Tyler I think).  I was looking for ways to speedup the hibernate startup.  Previous debugging in hibernate2 showed that the vast majority of time was spent in the cglib code building the proxies.  I've recently upgraded to hibernate3 so I thought I've have a crack myself.

I've followed the thought above about doing lazy setup at the Entity Persister level.  I've modified the AbstractEntityTuplizer and Environment with a new option to lazily create the proxy factories the first time createProxy() is called rather than in the constructor.  By default the old behaviour is used.  It uses an inner class that implements ProxyFactory to wrap up the lazy intialisation.

New config option is:

hibernate.use_lazy_proxy_factory true

This resulted in speedup of the hibernate buildSessionFactory() call (~10s to ~1.5s) so about 6-7 times and a 2.5-3 speedup of my overall app startup time.  I've only really done this for dev mode when a lot of restarts are required and I got bored of watching "building session factory".

It will an extremely useful little timesaver for me and other developers so I thought I'd post it here for anyone else to use and the hibernate team to use if they wish.

Dowsides of the solution are:

1) PersistentClass is kept in the lazy initialisation class for building the proxy factory.  Could be nulled out when the proxy factory is built for the first time to get it GCed

2) Unsure about thread-safety regarding cglib.  I'm pretty sure that the code is threadsafe but it may "see" an old null value in the LazyProxyFactory and create the factory again.  Could just synchronise the getProxy() method.  This has all been written so you can do whatever you want in the LazyProxyFactory without affecting anything when the new option is not specified.

3) The old code handled buildProxyFactory() returning null.  I don't know if/how this happens.  I would probably modify the lazy getProxy() to throw a descriptive exception if the buildFactory() returns null.  ("hibernate.use_lazy_proxy_factory option is not compatible with the current proxy configuration.  Please disable this option")


I'll attach the patches for the relevant patches shortly (once I figure out how to do a patch).

Cheers.

> startup time improvements
> -------------------------
>
>          Key: HHH-1258
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
>      Project: Hibernate3
>         Type: Improvement

>   Components: core
>     Versions: 3.1 rc3
>     Reporter: Max Rydahl Andersen
>     Assignee: Max Rydahl Andersen
>  Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira