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 > >> <emman...@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@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > -- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
