Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review
Hi
Yes, sure!. Give me some time, right now I'm doing some stuff related to
@ListenerFor annotation, so as soon as I'm done I'll take a look.
regards,
Leonardo
2010/9/30 Martin Koci martin.kocicak.k...@gmail.com
Hi,
Leonardo, can you please review :
MArtin,
your account is now setup - you even could apply them yourself,
after Leo did a successful review
-;M
On Thu, Sep 30, 2010 at 1:14 PM, Martin Koci
martin.kocicak.k...@gmail.com wrote:
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
Hi
Both optimizations are ok. +1
If you want I can commit it but I suggest you commit them.
regards,
Leonardo
2010/9/30 Matthias Wessendorf mat...@apache.org
MArtin,
your account is now setup - you even could apply them yourself,
after Leo did a successful review
-;M
On Thu, Sep 30,
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on MYFACES-2854-2.patch using
the suggestion
proposed (do
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on MYFACES-2862 we can
use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view
phase. It was *750
Hi,
today's results:
myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in
RestoreViewExecutor.exectute
mojarra: ~70 ms in RestoreViewPhase.execute
major gain comes from solution which I suggest in MYFACES-2854: process
resource dependecies only for type, not for each instance of that
Hi
2010/8/4 Martin Koci martin.k...@aura.cz
Hi,
today's results:
myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in
RestoreViewExecutor.exectute
mojarra: ~70 ms in RestoreViewPhase.execute
major gain comes from solution which I suggest in MYFACES-2854: process
resource
Leonardo Uribe píše v St 04. 08. 2010 v 14:26 -0500:
Hi
2010/8/4 Martin Koci martin.k...@aura.cz
Hi,
today's results:
myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in
RestoreViewExecutor.exectute
mojarra: ~70
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patchhttps://issues.apache.org/jira/secure/attachment/12451299/MYFACES-2854-2.patchusing
the suggestion
proposed (do not apply ResourceDependency if it was already processed). I
hope that
patch solve the problem.
regards,
Leonardo
https://issues.apache.org/jira/browse/MYFACES-2854
Martin Koci píše v Po 02. 08. 2010 v 22:20 +0200:
Hi,
quick results: yourkitprofiler marks as hot spot
UiViewRoot.addComponentResource (3381 invocation count) - that method
itself creates 5 710 511 invocations of AbstractIterator.next()
Hi,
our profiling results show that myfaces are significantly slower in
restore view phase:
com.sun.faces LifeCycle .. restoreView : 80 ms
o.a.m.RestoreViewExecutor : 750ms!
This result is perfectly reproducible in our case. I profile it on a
application real application - I cannot post
Hey,
I'm very interested in the details behind those 750ms. Can you post
the hotspots? Like: number of invocations, ms. self time and ms. total time.
Thanks.
Regards,
Jan-Kees
2010/8/2 Martin Koci martin.k...@aura.cz
Hi,
our profiling results show that myfaces are significantly slower in
Martin,
We've been seeing some similar bottlenecks in our testing on Websphere.
We've think we have it isolated down to where the largest portion of the
impacts are coming from checkResourceExists() in
DefaultViewHandlerSupport and DefaultRestoreViewSupport. The problem,
at least in our
UIInput is slow, we already have bugs for that
-Matthias
On Mon, Aug 2, 2010 at 7:18 PM, Jan-Kees van Andel
jankeesvanan...@gmail.com wrote:
Hey,
I'm very interested in the details behind those 750ms. Can you post
the hotspots? Like: number of invocations, ms. self time and ms. total time.
One thing I noticed while testing my Ajax stuff is that Mojarra has some
ViewScope optimizations, in MyFaces a deserialisation method I set on a
ViewScoped bean always got called. In Mojarra it never was in the ppr case.
I can run my tests again to get the exact behavior.
Also have a serious
Hi
There is an issue open related to checkResourceExists() call:
MYFACES-2628 Facelets ResourceSolver cant work : Make this call crash
facelets ResourceSolver, it was suggested this issue.
The previous evidence suggest the following line:
ViewDeclarationLanguage vdl =
Hi,
quick results: yourkitprofiler marks as hot spot
UiViewRoot.addComponentResource (3381 invocation count) - that method
itself creates 5 710 511 invocations of AbstractIterator.next()
Reason probably is that I have custom renderer for UInput with
@ResourceDependencies(...many
20 matches
Mail list logo
