jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: Fwd: [jsr344-experts] [941-ReduceELCalls] DISCUSSION

From: Hanspeter <hampidu_at_gmail.com>
Date: Sat, 10 Jan 2015 00:18:09 +0100

Hi Experts.

I think this is worth pushing +1.

The multiple rendered attribute evaluation bothers most in the render phase
because isRendered() is called by every UIComponent(Base).encode* method.
So maybe a first step would be to improve the encode* methods such that for
an encodeAll() cycle the rendered attribute is cached. That is possible
with a few lines of code - I happily provide the changes.

E.g. encodeAll() and/or encodeBegin() could enable renderedCaching,
isRendered() stores the rendered result on a component private Boolean, and
in encodeEnd() rendered caching is disabled and reset. That way without
additional effort rendered is reset for the next iteration. But still this
would reduce evaluate times by factor 3 to 4 per component encoding.

I'm not sure whether rendered caching on a broader scope makes sense, e.g.
for phases 2-5. In csJSF component library we did some rendered caching,
but had to reset the cache once per phase and within iterating components
as well. And I think rendered is rarely evaluated more often as it was
reset in these execution phases.

Best regards
Hanspeter



2015-01-09 19:12 GMT+01:00 Bauke Scholtz <balusc_at_gmail.com>:

> +1
>
> Ideally, the UIComponent#isRendered() should cache the value on a
> per-phase and per-iteration basis. It would be awesome too if iteration
> components implement a common interface or abstract class, which should
> also simplify a lot of other things related to a.o. setting the currently
> iterated item and state saving.
>
> Cheers, B
>
>
> On Fri, Jan 9, 2015 at 7:00 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
>
>> Whoops, sending to right list. Please ignore it on the other.
>>
>> -------- Original Message -------- Subject: [jsr344-experts]
>> [941-ReduceELCalls] DISCUSSION Date: Fri, 09 Jan 2015 11:51:14 -0600 From:
>> manfred riem <manfred.riem_at_oracle.com> <manfred.riem_at_oracle.com> Reply-To:
>> jsr344-experts_at_javaserverfaces-spec-public.java.net Organization: Oracle
>> Corporation To: jsr344-experts_at_javaserverfaces-spec-public.java.net CC:
>> Max Starets <max.starets_at_oracle.com> <max.starets_at_oracle.com>, Andy
>> Schwartz <andy.schwartz_at_oracle.com> <andy.schwartz_at_oracle.com>
>>
>> Hi all,
>>
>> As we all know the number of times an EL expression is evaluated during
>> render is higher than it could be.
>>
>> To see if there is a potential to reduce that number I want to ask the
>> most important question first as it determines whether or not this issue is
>> even worth pursuing?
>>
>> *Is it safe to assume that during rendering and not as a child of an
>> iterating component the value of the EL expression will stay stable?*
>>
>> Regards,
>> Manfred
>>
>>
>