[hibernate-dev] Optimizing reflection optimization

[Steve Ebersole]

Perhaps it short circuits those copies and other overheads if no
security manager is defined (ala as in my IDE).  That would explain how
I can see minimal improvement while Kirill sees a 4x improvement.

Still rather confirm these numbers are accurate.  Kirill?

On Thu, 2010-05-27 at 10:12 -0400, Bill Burke wrote:
> Carlo deWolfe found that one of the big perf problems with Java 
> reflection is that it is constantly doing security checks with the 
> security manager and every get/find request makes a copy of the 
> method/field objects.  He had a hack for this, but you'll have to 
> consult him on what it is.  The JBoss Reflections project might have it.
> 
> I think once this hack is intiated, it is an improvement over Javassist. 
> If you think about it, Java VM has to build up this information anyways...
> 
> Steve Ebersole wrote:
> > I ran this same exact comparison before and I seem to recall much
> > different results.  Unfortunately I no longer have that code.  This was
> > part of
> > http://opensource.atlassian.com/projects/hibernate/browse/HHH-227
> > 
> > Can you make sure you "prime" or "warm up" the jvm before you start
> > taking measurements?  
> > 
> > On Thu, 2010-05-27 at 15:39 +0300, Кирилл Кленский wrote:
> >> Hi,
> >>
> >> My measurements have indicated that there is a performance gain. I have
> >> measured the time spent in setPropertyValues and getPropertyValues.
> >> The optimized version was 4 times faster in these methods giving an
> >> estimated application performance increase of about 3%.
> >> Optimizing getPropertyValue and setPropertyValue could give 1.5% more
> >> according to our rough calculations.
> >>
> >> Kirill
> >>
> >> 26 мая 2010 г. 23:53 пользователь Emmanuel Bernard
> >> <emmanuel at hibernate.org>написал:
> >>
> >>> Hi,
> >>> Have you noticed a perf difference in your application with and without the
> >>> patch?
> >>> I am wondering if modern VMs have catched up with what Javassist does.
> >>>
> >>> On 26 mai 2010, at 18:29, Кирилл Кленский wrote:
> >>>
> >>>> 1. I have noticed that
> >>>> org.hibernate.bytecode.javassist.BulkAccessorFactory.findAccessors(...)
> >>> is
> >>>> searching for accessor methods in the optimized entity class only. This
> >>>> means that the methods from the superclasses are not visible during
> >>>> BulkAccessor creation unless overridden by child classes. By enhancing
> >>> the
> >>>> algorithm to search down the inheritance tree we could avoid creation of
> >>>> redundant methods which increase the code verbosity a lot. In our case
> >>>> almost all the entities are inherited from the base classes having the
> >>>> common entity properties defined, so the reflection optimization does not
> >>>> work for any of them until we override the inherited methods in all the
> >>>> child classes. The implementation is trivial, but I have got a ready
> >>>> prototype if anybody is interested.
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > 
> 


-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org