[core] performance: preinitialize facelets and analyze views (during startup)

[Martin Koci <ma...@gmail.com>]

Hi,

Can we find a way how to pre-initialize all .xhtml (Facelet instances)
during startup? I think that can bring many improvements, for example:

-- Minimize sychronized:

---- populate all cached Value|MethodExpression on TagAttributeImpl
(MYFACES-3160) - than we can remove volatile keyword

---- populate cache in JUEL/EL: JUEL has own cache for expressions based
on ConcurrentHashMap - we can use plain HashMap without lock 


-- Syntax-check (precompilation) - is syntactically ok? Currently the
only way how to check all views in app is perform a request to each one.

-- Statistics about views:

---- usage of c: (build-time) tags in view

---- analyze structure, for example for common mistakes (like
f:viewParam in template)

Then we can try VLD.buildView with InitFacesContext and provide some
useful statistic data:

---- provide hints for user (for example analyze structure of
h:dataTable  and if it contains no EditableValueHolder, 
provide readOnly hint )

....

WDYT?


Regards,

Kočičák

Re: [core] performance: preinitialize facelets and analyze views (during startup)

[Leonardo Uribe <lu...@gmail.com>]

Hi

2011/6/13 Martin Koci <ma...@gmail.com>:
> Hi,
>
> Can we find a way how to pre-initialize all .xhtml (Facelet instances)
> during startup?

At first view, the problem is how to locate all facelets .xhtml or
.view.xml of a webapp. We have the same problem with annotation
scanning: web servers could provide its own structure to handle files,
so in practice we need a way to delegate that scanning to the server
through a SPI interface.

The other problem is we are assuming something about the .xhtml or
.view.xml files. It is known some files could be retrieved from a
database, and don't forget ResourceResolver interface, which can be
configured to load facelets from jar files.

> I think that can bring many improvements, for example:
>
> -- Minimize sychronized:
>
> ---- populate all cached Value|MethodExpression on TagAttributeImpl
> (MYFACES-3160) - than we can remove volatile keyword

I don't think we can make it without break ResourceResolver.

>
> ---- populate cache in JUEL/EL: JUEL has own cache for expressions based
> on ConcurrentHashMap - we can use plain HashMap without lock
>

I don't know the details behind JUEL. Our ideal is keep all info
related to a facelet
that does not change in the facelet Abstract Syntax Tree (AST), so if we can
store only the parsing info of an expression inside that could be
great, but does
not sounds easy, because care must be taken to specific code to JUEL without
break binary compatibility with other EL libraries.

>
> -- Syntax-check (precompilation) - is syntactically ok? Currently the
> only way how to check all views in app is perform a request to each one.
>

There is another alternative. Use FaceletsTestCase from myfaces-impl package.

This class is on myfaces-impl-2.x.x-test.jar, available on maven repo, and it is
widely used to test facelets files. In theory, you can create a test
case extending
from that class that do the check for you.

I like this approach, because you can see errors on development time, so the
final war will be facelet-tags error free, and with maven you see it
as a test error
after each build.

> -- Statistics about views:
>
> ---- usage of c: (build-time) tags in view
>
> ---- analyze structure, for example for common mistakes (like
> f:viewParam in template)
>
> Then we can try VLD.buildView with InitFacesContext and provide some
> useful statistic data:
>
> ---- provide hints for user (for example analyze structure of
> h:dataTable  and if it contains no EditableValueHolder,
> provide readOnly hint )
>

The remaining points sounds good. But note do that will make setup
time longer. We didn't dedicate too much time to make myfaces setup
faster. I know there are some opportunities there, like do some task
in parallel (since myfaces is on a web server, why use a single thread
to initialize everything?). If the idea proposed here is done, we have
to tune myfaces startup time to keep some balance there.

regards,

Leonardo Uribe

> ....
>
> WDYT?
>
>
> Regards,
>
> Kočičák
>
>

Re: [core] performance: preinitialize facelets and analyze views (during startup)

[Jakob Korherr <ja...@gmail.com>]

Hi Martin,

Sounds nice. I would like to see some patches for this stuff - hehe :)

Regards,
Jakob

2011/6/13 Martin Koci <ma...@gmail.com>:
> Hi,
>
> Can we find a way how to pre-initialize all .xhtml (Facelet instances)
> during startup? I think that can bring many improvements, for example:
>
> -- Minimize sychronized:
>
> ---- populate all cached Value|MethodExpression on TagAttributeImpl
> (MYFACES-3160) - than we can remove volatile keyword
>
> ---- populate cache in JUEL/EL: JUEL has own cache for expressions based
> on ConcurrentHashMap - we can use plain HashMap without lock
>
>
> -- Syntax-check (precompilation) - is syntactically ok? Currently the
> only way how to check all views in app is perform a request to each one.
>
> -- Statistics about views:
>
> ---- usage of c: (build-time) tags in view
>
> ---- analyze structure, for example for common mistakes (like
> f:viewParam in template)
>
> Then we can try VLD.buildView with InitFacesContext and provide some
> useful statistic data:
>
> ---- provide hints for user (for example analyze structure of
> h:dataTable  and if it contains no EditableValueHolder,
> provide readOnly hint )
>
> ....
>
> WDYT?
>
>
> Regards,
>
> Kočičák
>
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at