myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [core] performance: an optimal ELResolvers chain for POJO-based apps
Date Tue, 29 Mar 2011 18:44:07 GMT
Hi

MK >> The obvious optimalization would be move the BeanELResolver to top.
But
MK >> you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is
not
MK >> found or is not readable, a PropertyNotFoundException is thrown."  So
MK >> UEL spec. mandates that BeanELResolver must be last one which resolves
MK >> not-null base and a property on that base.

MK >> Do you know the reason for that? Do you have any ideas how to move
MK >> BeanELResolver to top and avoid thousands of "empty" geValue
MK >> invocations?

If BeanELResolver is on top, other resolvers like MapELResolver will fail. I
don't
think that could be possible.

Maybe we need to think about a solution for override EL resolvers chain,
maybe
through a SPI interface.

regards,

Leonardo Uribe

2011/3/29 Martin Koci <martin.kocicak.koci@gmail.com>:
> Hi,
>
> the only solution which comes to my mind is update MYFACES-3075 to
> support transforming (replacing one resover with another) and with some
> sort of supplier support (when user wants provide own list of EL
> reolvers). That will allow complete maninulation of el resolvers chain:
> custom chain,sort,filter and transform.
>
> Then we can provide a lenient BeanELResolver implementation with
> behaviour: if base does not have the property returns null and allows
> next resolver to take charge of getValue.
>
> WDYT?
>
> Kočičák
>
> Martin Koci píše v Po 28. 03. 2011 v 20:50 +0200:
>> Hi,
>>
>> I'm optimizing render response on a large view (takes over 3 secs to
>> render) and below you can see results of unsorted and unfiltered
>> ELResolvers chain. The most important info is that  BeanELResolver
>> resolves property over 40000x from 64000 invocations. The second place
>> belongs to ImplicitObjectResolver with over 20000 resolved properties.
>> The reason why BeanElResolver is so successful is because majority of
>> expressions looks like
>> {requestScope.pojoObject.propertyOne.propertyTwo}.
>>
>>
>> The obvious optimalization would be move the BeanELResolver to top. But
>> you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is not
>> found or is not readable, a PropertyNotFoundException is thrown."  So
>> UEL spec. mandates that BeanELResolver must be last one which resolves
>> not-null base and a property on that base.
>>
>> Do you know the reason for that? Do you have any ideas how to move
>> BeanELResolver to top and avoid thousands of "empty" geValue
>> invocations?
>>
>> Thanks,
>>
>> Kočičák
>>
>>
>> Results:
>> ImplicitObjectResolver:
>> getValue invocations: 64452 getValue hits: 21018
>>
>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
>> getValue invocations: 64336 getValue hits: 30
>>
>> org.richfaces.skin.SkinPropertiesELResolver
>> getValue invocations: 64306 getValue hits: 0
>>
>> org.richfaces.resource.ResourceParameterELResolver
>> getValue invocations: 64306 getValue hits: 0
>>
>> org.jboss.weld.environment.servlet.jsf.WeldApplication
>> $LazyBeanManagerIntegrationELResolver
>> getValue invocations: 64306 getValue hits: 975
>>
>> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
>> getValue invocations: 63331 getValue hits: 0
>>
>> org.apache.myfaces.el.unified.resolver.ResourceResolver
>> getValue invocations: 63331 getValue hits: 64
>>
>> javax.el.ResourceBundleELResolver
>> getValue invocations: 63267 getValue hits: 3
>>
>> org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
>> getValue invocations: 63264 getValue hits: 3
>>
>> javax.el.MapELResolver:
>> getValue invocations: 63261 getValue hits: 1069
>>
>> javax.el.ListELResolver:
>> getValue invocations: 62192 getValue hits: 0
>>
>> javax.el.ArrayELResolver:
>> getValue invocations: 62192 getValue hits: 0
>>
>> javax.el.BeanELResolver:
>> getValue invocations: 62192 getValue hits: 40563
>>
>> org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
>> getValue invocations: 21629 getValue hits: 582
>>
>>
>
>
>

Mime
View raw message