[
https://issues.apache.org/jira/browse/MYFACES-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13918093#comment-13918093
]
Karl Trumstedt edited comment on MYFACES-3863 at 3/3/14 2:26 PM:
-----------------------------------------------------------------
I use JProfiler. But for this I had just added debug messages to a
phaseListener. For me I guess that I felt that the validation phase always was
a waste of time since we don't use the <f:validator> tags. Even if it was a
rather simple page with ~50-100 components there could be 10-20 ms in the
validation phase. We are hunting for each and every ms we can save!
We have tables with 10's of thousands of rows, 20-100 columns wide. Doing a
post back with this beast can waste 2-3 seconds in the validation phase. I
don't know how much time the debugging adds though. For some of these tables we
can't have paging due to requirements which is sad, but we're fighting for
alternative solutions to reduce table sizes!
facesContext.renderRepsonse() skips all coming phases as far as I know so it's
not an option? But we can live with this I guess, I just felt like this could
be an performance improvement for huge pages :)
was (Author: guitarkalle):
I use JProfiler. But for this I had just added debug messages to a
phaseListener. For me I guess that I felt that the validation phase always was
a waste of time since we don't use the <f:validator> tags. Even if it was a
rather simple page with ~50-100 components there could be 20 ms in the
validation phase. We are hunting for each and every ms we can save!
We have tables with 10's of thousands of rows, 20-100 columns wide. Doing a
post back with this beast can waste 2-3 seconds in the validation phase. I
don't know how much time the debugging adds though. For some of these tables we
can't have paging due to requirements which is sad, but we're fighting for
alternative solutions to reduce table sizes!
facesContext.renderRepsonse() skips all coming phases as far as I know so it's
not an option? But we can live with this I guess, I just felt like this could
be an performance improvement for huge pages :)
> Possible performance enchanchment in postback lifecycle processing
> ------------------------------------------------------------------
>
> Key: MYFACES-3863
> URL: https://issues.apache.org/jira/browse/MYFACES-3863
> Project: MyFaces Core
> Issue Type: Improvement
> Reporter: Karl Trumstedt
> Assignee: Leonardo Uribe
> Priority: Minor
>
> Hello,
> I've been looking and reading a lot about JSF's lifecycle. I'm no expert in
> any sense and have not fully grasped what happens in each phase.
> I have debugged our application and seen how much time is spent in each
> cycle. For larger pages it can be quite a lot (500 ms for each APPLY,
> VALIDATION, UPDATE). Even for smaller pages there can be ~10-20ms in the
> cycle when posting to the server. As far as I have gathered, the component
> tree is traversed for each of these cycles. For us, every ms counts :)
> Now, my application doesn't use the JSF validation framework. There isn't any
> <f:validator> stuff anywhere. For me, I don't see that I need to execute that
> phase, ever. So I would like to turn off that phase. But even better, maybe
> when parsing the XHTML facelet (or constructing the view or something),
> couldn't the UIViewRoot have information on if there are any <f:validator>
> stuff on the page? If not, it could skip the validation phase completely?
> As I said, I don't fully grasp what's happening behind the scenes so maybe
> something else would stop working? And maybe the validation phase does more
> the execute <f:validator> tags.
> I realize this scenario might be special since we don't use the <f:validator>
> stuff, we reuse our own legacy validation framework, but there still could be
> pages in a regular JSF application with lots of components (big tables etc)
> and no validation (or custom validation). Any pointers for how I could patch
> and skip the validation phase myself would be nice:)
> Thanks
--
This message was sent by Atlassian JIRA
(v6.2#6252)
