[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_25463 ] 

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

#1: I realise this a configuration level object rather than a run-time one so ideally it wouldn't be kept hanging around but I didn't see an easy way of doing this.  You could null it out once the factory is created to have it reclaimed.  Don't know about the event listener stuff, I'm new to H3.

#2: Just adding synchronized to the getProxy() method of the LazyProxyFactory would do it.  It's certainly safer, not sure if it is necessary.  I believe this will work with any byte code plugin because that is all hidden behind the buildProxyFactory() protected abstract.  All this patch does is delay that initial call from construction time to first-proxy-request time.  I haven't tested with javaassist specifically only cglib.

#3: In the old code the constructor of AbstractEntityTuplizer did the following:

 		if ( entityMetamodel.isLazy() ) {
			proxyFactory = buildProxyFactory( mappingInfo, idGetter, idSetter );
			if (proxyFactory == null) {
				entityMetamodel.setLazy( false );
			}
		}

So if the proxy factory creation returned null it would set the entity model to non-lazy.  I would've thought an exception would be better than silently setting the model to non-lazy but maybe I'm missing something.

The lazy wrapper does not expect a null return from buildProxyFactory() at the moment so this would have to checked and an exception thrown if a null return is possible.  At this point I suspect it is not safe to set the entity model back to non-lazy.


I'll make the synchronization, null out of PersistentClass and check of null return from buildProxyFactory() and resubmit in a single patch file.

I'll run the result through the test suite, see if there's any major problems.

Feel free to delete the old attachments I made.

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: AbstractEntityTuplizer.patch, Environment.patch, 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