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(a)hibernate.xn--org>-8fga3f8au1a3a:
>>
>>> 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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>