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: custom implicit objects
Date Wed, 10 Aug 2011 04:20:43 GMT
Hi Gerhard

2011/8/9 Gerhard Petracek <gerhard.petracek@gmail.com>:
> 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.

But precisely that's the point. My theory at first view (and as any
theory untested yet) is any optimization here will be marginal,
because it should "assume" some specific EL chain and practically it
will do the same as the code without use it. A custom el-resolver
could break the optimization, because it should impose some "contract"
and the custom one could not preserve it.

> 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.

That could help.

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
>>
>> 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