myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerhard Petracek <gerhard.petra...@gmail.com>
Subject Re: [core] performance: custom implicit objects
Date Tue, 09 Aug 2011 21:18:21 GMT
hi leo,

we don't have control over the performance of custom el-resolvers.
the comparator would help but then we are again at the point mentioned by
martin.

for sure we can do both. to get a first impression, we don't have to
prototype all edge cases.
e.g. we can test it by just mapping a custom el-resolver (e.g. the owb
el-resolver). that doesn't take that much time (if it works at all).

however, maybe martin can provide some concrete numbers.

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2011/8/9 Leonardo Uribe <lu4242@gmail.com>

> Hi
>
> 2011/8/9 Gerhard Petracek <gerhard.petracek@gmail.com>:
> > hi leo,
> > that's why i asked martin concerning results and he answered that he can
> see
> > a big difference.
> > currently we just think about different approaches. that doesn't mean
> that
> > we commit something to the trunk within the next days.
> > if we prototype such an improvement, we have to do it e.g. in a branch
> and
> > measure the differences (just a real comparison will show the difference
> and
> > no theoretical discussion).
>
> Yes, but note a comparison against some ELResolvers without review
> them could lead to wrong conclusions. First we need to check if the
> current implementation of our ELResolvers runs fast enough and then do
> the comparison.
>
> Anyway I don't understand why try an optimization without know how it
> can enhance performance. It sound like a trial and error approach, and
> probably it will waste a lot of time and resources that can be saved
> with a good analysis.
>
> regards,
>
> Leonardo Uribe
>
> > regards,
> > gerhard
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> > 2011/8/9 Leonardo Uribe <lu4242@gmail.com>
> >>
> >> Hi
> >>
> >> I have doubts about if we are really looking on the real source of the
> >> problem, or if some hack can improve the speed of the code. In theory
> >> each EL resolver do a quick-check before do the real work. Thinking
> >> about a solution based on the previous comments, I don't see where is
> >> the improvement, because after all, we need to do all the steps that
> >> are doing the chain right now.
> >>
> >> I think the trick is check carefully each resolver and what is doing,
> >> and enhance that part.  Remember that is "expensive" is not an
> >> interation over an array, is the comparisons, lookups to maps or other
> >> code that is executed over and over.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2011/8/9 Martin Koci <martin.kocicak.koci@gmail.com>:
> >> > Hi,
> >> >
> >> > I also agree (with  Gerhard) that in first place it is better to some
> >> > improvements in myfaces core (without unnecessary burden for clients).
> >> >
> >> >
> >> > But it is not easy (or even possible?) to intercept EL expression
> >> > evaluation, because the only API we can use in myfaces is ELResolver
> and
> >> > method getValue. Evaluation of EL Expression itself is internal part
> of
> >> > EL impl and I don't see any elegant way how to detect that evaluated
> >> > base or property in ELResolver.getValue() is root bean or not. Any
> >> > ideas?
> >> >
> >> >
> >> > More about custom imlicit objects:
> >> > I still think that the idea is good and myfaces or JSF generally
> should
> >> > support it. Use cases:
> >> >
> >> > 1) Custom implicit object for render kits and JSF libraries like
> "skin".
> >> > For example, richfaces have own ELResolver  and they use a managed
> bean
> >> > in it [1].
> >> >
> >> > 2) project-specific implicit object. Many projects has something like
> >> > "projectConfiguration" with properties like version:
> >> > #{projectConfiguration.version}. Currently the projectConfiguration
> must
> >> > be managed-bean or IoC container (CDI, Spring) managed and named bean.
> >> > With possibility of custom implicit object, project can define own
> names
> >> > and optimize EL resolving for object where managed bean is an
> performace
> >> > overhead (configuration in this example can be a instance of
> Properties
> >> > and completely unmanaged). Imlicit object is de facto a well-known
> >> > build-in named bean.
> >> >
> >> > 3) Jakob mentioned JSF managed-beans. In this case two managed beans
> can
> >> > have same name and different scope. User can specify
> >> > #{sessionScope.sameName} and #{requestScope.sameName} to differentiate
> >> > them. It this possible for CDI beans too?
> >> >
> >> > Everything has advantages and disadvatages and I think (custom)
> implicit
> >> > objects is underestimated area in JSF that has it's purpose in
> specific
> >> > use cases.
> >> >
> >> > Regards,
> >> >
> >> > Kočičák
> >> >
> >> > [1] https://issues.jboss.org/browse/RF-10755
> >> >
> >> > Jakob Korherr píše v Út 09. 08. 2011 v 19:35 +0200:
> >> >> Hi,
> >> >>
> >> >> That's a good idea, however we need to be very careful with such
> >> >> improvements. There are some cases in which you need different EL
> >> >> resolvers for the "same" object. For example, JSF managed beans are
> >> >> created by the ManagedBean EL resolver (very late in the chain), but
> >> >> if they already exist, they are resolved by the respective scope EL
> >> >> resolver (e.g. session EL resolver for @SessionScoped managed beans).
> >> >>
> >> >> Please keep that in mind!
> >> >>
> >> >> Regards,
> >> >> Jakob
> >> >>
> >> >> 2011/8/8 Gerhard Petracek <gerhard.petracek@gmail.com>:
> >> >> > hi martin,
> >> >> > a smarter approach might be useful. e.g. after the first lookup
of
> a
> >> >> > root-bean myfaces-core could store the el-resolver which found
the
> >> >> > bean in a
> >> >> > mapping.
> >> >> > before the resolver chain gets invoked, myfaces-core could do
a
> >> >> > lookup in
> >> >> > the stored mapping and use the mapped el-resolver (if there is
> one).
> >> >> > if the
> >> >> > el-resolver can't resolve the bean any more (or there is no mapped
> >> >> > el-resolver), the whole chain would be invoked as usual.
> >> >> > regards,
> >> >> > gerhard
> >> >> >
> >> >> > 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 <martin.kocicak.koci@gmail.com>
> >> >> >>
> >> >> >> Gerhard Petracek píše v Po 08. 08. 2011 v 16:36 +0200:
> >> >> >> > hi martin,
> >> >> >> >
> >> >> >> >
> >> >> >> > i think most users will be fine with the
> >> >> >> > OpenWebBeansELResolverComparator [1]
> >> >> >>
> >> >> >> yes, this comparator moves OWB resolver to the last posititon.
> Thas
> >> >> >> good
> >> >> >> because most of the EL expression nodes are generally not
cdi
> beans
> >> >> >> names. Custom implicit object was only proposition how to
specify
> >> >> >> that
> >> >> >> following node in expression is CDI bean.
> >> >> >>
> >> >> >> >  and a custom InterceptorHandler (btw. an add-on like
the
> >> >> >> > scope-boost
> >> >> >> > for codi).
> >> >> >> I'll take a look at it.
> >> >> >>
> >> >> >> > (esp. because an implicit variable would also break e.g.
ide
> >> >> >> > support.)
> >> >> >> >
> >> >> >> yes, that is a disadvantage. But generally IDEs must support
> >> >> >> something
> >> >> >> like that, because custom scopes are possible in JSF 2.0
> >> >> >>
> >> >> >> > however, if you have concrete numbers, we could start
a vote
> about
> >> >> >> > it.
> >> >> >> >
> >> >> >>
> >> >> >> with 100 000 and more invocation of CompositeELResolver.getValue
> >> >> >> during
> >> >> >> one render response is improvement noticeable, especially
if every
> >> >> >> EL
> >> >> >> expression is #{someCDIBean.someProperty}
> >> >> >>
> >> >> >> But I incorrectly mixed together two problems:
> >> >> >>
> >> >> >> 1) posibility of custom implicit objects for myfaces core,
> >> >> >> independent
> >> >> >> from usage.
> >> >> >>
> >> >> >> 2) example of usage : CDI/CODI integration.
> >> >> >>
> >> >> >> >
> >> >> >> > regards,
> >> >> >> > gerhard
> >> >> >> >
> >> >> >> >
> >> >> >> > [1]
> https://cwiki.apache.org/confluence/display/MYFACES/ELResolver
> >> >> >> > +ordering
> >> >> >> >
> >> >> >> > 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 <martin.kocicak.koci@gmail.com>
> >> >> >> >         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 <martin.kocicak.koci@gmail.com>
> >> >> >> >         >         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
> >> >> >> >         >
> >> >> >> >         >
> >> >> >> >         >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >
> >
>

Mime
View raw message