ICEfaces-EE
  1. ICEfaces-EE
  2. IPCK-204

Rich Data Grid peformance issues.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-2.0.0.Alpha1
    • Fix Version/s: EE-2.0.0
    • Component/s: Facelet Components
    • Labels:
      None
    • Environment:
      jsf 2.1

      Description

      The Rich Data component is seems to work as advertised if everything is done very slowly and the Lifecycle is allowed to finish between requests. The component needs few seconds to render in the render response phase which seems to kill the bridge code if the demo/component is quick clicked on.

      The component should be looked at to see if anything can be done to optimize the render time of the component. The behaviour seem about the same in 1.8.2 .

        Issue Links

          Activity

          Hide
          Ken Fyten added a comment -

          It seems that some of the performance issues might be related to the general use of the icecore:singleSubmit tag in the demo application. This is causing any visited input fields, such as data entry fields in editable datable, to do a singleSubmit onblur. This adds numerous extra submits and lifecycles and is not necessary for this demo as it's written to valid, etc. on "save" by clicking the save button.

          Changes should be made to the structure of the sample app. to avoid using singleSubmit in a blanket fashion, so that each demo can apply it as required.

          Show
          Ken Fyten added a comment - It seems that some of the performance issues might be related to the general use of the icecore:singleSubmit tag in the demo application. This is causing any visited input fields, such as data entry fields in editable datable, to do a singleSubmit onblur. This adds numerous extra submits and lifecycles and is not necessary for this demo as it's written to valid, etc. on "save" by clicking the save button. Changes should be made to the structure of the sample app. to avoid using singleSubmit in a blanket fashion, so that each demo can apply it as required.
          Hide
          Ken Fyten added a comment -

          Suggested changes to blanket use of singleSubmit noted above have been implemented. This demo is still fairly slow, however. Perhaps if the two tables were put in separate demos that would help? (I'm assuming each one demonstrates some unique from the other in terms of component features or usage that warrants keeping both).

          Show
          Ken Fyten added a comment - Suggested changes to blanket use of singleSubmit noted above have been implemented. This demo is still fairly slow, however. Perhaps if the two tables were put in separate demos that would help? (I'm assuming each one demonstrates some unique from the other in terms of component features or usage that warrants keeping both).
          Hide
          Philip Breau added a comment -
          • move inline css to external file
          • remove popup menu from all columns and put only in last column
          • moved hidden columns popup menu into column headers (was in the top pager info panel), to avoid resending menu content in frequent dom diffs for the changing pager info
          • trifurcated the rich data grid layout so that the header and footer are not sent in the dom diff when the table data changes (header and footer dom placement changed to separate siblings of data)

          performance is now noticeably improved.

          Filtering:

          • dom updates are much smaller
          • filtering much improved as focus is maintained while quickly typing

          HTML weight:
          -rendered weight is much reduced, will depend on specific table layout and data, but the 1st comp showcase example reduced ~40%
          -dom diff sizes are significantly reduced as well

          Show
          Philip Breau added a comment - move inline css to external file remove popup menu from all columns and put only in last column moved hidden columns popup menu into column headers (was in the top pager info panel), to avoid resending menu content in frequent dom diffs for the changing pager info trifurcated the rich data grid layout so that the header and footer are not sent in the dom diff when the table data changes (header and footer dom placement changed to separate siblings of data) performance is now noticeably improved. Filtering: dom updates are much smaller filtering much improved as focus is maintained while quickly typing HTML weight: -rendered weight is much reduced, will depend on specific table layout and data, but the 1st comp showcase example reduced ~40% -dom diff sizes are significantly reduced as well

            People

            • Assignee:
              Philip Breau
              Reporter:
              Patrick Corless
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: