Hi,
the OWB el-resolver itself is fast enough, thats not the problem. The
problem is when you use CDI managed bean in big ELResolver chain. For
example, consider this chain:
ImplicitObjectResolver
MapELResolver
ResourceResolver
CompositeComponentELResolver
VariableResolverToELResolver
PropertyResolverToELResolver
FlashELResolver
ManagedBeanResolver
ResourceBundleELResolver
ResourceBundleResolver
ListELResolver
ArrayListResolver
org.apache.webbeans.el.WebBeansELResolver
SkinPropertiesELResolver
ResourceParametrELResolver
javax.el.BeanELResolver
then when resolving #{cdiScopeBean} EL impl must call first 12 resolvers
and none of them sets elContext.setPropertyResolved(true)
Old JSF style can shorten it with #{sessionScope.sessionScopedBean} for
example and then resolving takes only first two resolvers because
MapELResolver sets propertyResolved(true)
so I'm looking for a solution how to minimize "void" usage of
ELresolvers and how to say directly that "this is CDI bean and use CDI
ELResolver for it"
Gerhard Petracek píše v Po 08. 08. 2011 v 15:50 +0200:
> hi martin,
>
>
> the real overhead (after our recent improvements) is the overhead of
> the proxy itself.
>
>
> in owb we have a cache in the el-resolver as well as in
> some implementations of InterceptorHandler. the upcoming version of
> owb will allow to use such special caches also for custom scopes.
> e.g. there is a scope-boost add-on [1] for codi. so you get contextual
> instances which are cached in a thread-local and the add-on also has
> to do the reset of the cache (as soon as it is needed - that depends
> on the concrete scope).
>
>
> since we already have two caches in place and the real overhead is in
> the proxy implementation, i'm not sure if we really get more
> performance with such a spi.
>
>
> (mark also implemented a cache for methods which aren't intercepted. i
> already tested it and depending on the constellation the increase in
> performance is about 5%.)
>
>
> regards,
> gerhard
>
>
> [1] http://os890.blogspot.com/2011/08/benchmark-boost-myfaces-codi-scopes.html
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
>
>
>
> 2011/8/8 Martin Koci <[email protected]>
> Hi,
>
> if user uses plain old JSF style with managed beans like:
>
> #{sessionScope.mySessionScopedBean} or
> #{requestScope.myRequestScopedBean} or
> #{requestScope.varFromDataTable.property}
>
> it can achieve excellent performance during render response
> phase,
> because every EL resolution takes only two steps:
>
> 1) o.a.m.ImplicitObjectResolver resolves sessionScope or
> requestScope to
> java.util.Map
> 2) javax.el.MapELResolver reads map.get("mySessionScopedBean")
> and sets
> elContext.setPropertyResolved
>
> (at first access ManagedBeanResolver must create bean instance
> but we
> can ignore it for simplicity).
>
> Specially if user uses EL resolvers ordering [1] and creates
> chain of
> (ImlicitObjectResolver,MapELResolver, other resolvers) then
> resolving
> takes only two first resolvers.
>
>
> Now compare it with situation where CDI is used. Because
> CDI/OWB
> resolver is not so fast as default el resolvers, common usage
> is put it
> at bottom of resolvers chain with
> OpenWebBeansELResolverComparator. Then
> resolving must go thru all ELresolvers in chain (12 or more
> resolvers)
> to find a @Named bean.
>
>
> How to improve this? One thing can be use custom implicit
> object for
> this
> 1) create ImplicitObjectsProvider SPI interface in myfaces
> 2) CDI and CDI extension will add own implementation of
> myfaces
> ImlicitObject, for example #{codiWindowScope} from CODI
> 3) the resolved value from implicit object can mimic the map
> interfaces
> (for example WindowScopeMap) to preserve behaviour of servlet
> scopes and
> to use MapELResolver
>
> WDYT? Any other ideas?
>
>
> Regards,
>
> Kočičák
>
> [1] https://cwiki.apache.org/MYFACES/elresolver-ordering.html
>
>
>
