Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    issues with grid editing performance with editByCell

    Hi there, we are trying to enable editing on a grid that has approximately 800 fields defined on the Datasource. This is a grid with lots and lots of read-only data. The visible, editable fields on the grid typically total only about 10-15 and we have editByCell turned to true. However, we are seeing major performance problems when clicking from one editable cell to another. I have a few questions to help me sort out how to resolve these issues

    1. It looks like the hideInlineEditor() call when you click from one cell to another calls recordHasChanges() which is very expensive with so many datasource fields. If we have editByCell turned on and thus you can only edit one cell at a time, does the framework need to call recordHasChanges() in that case?

    2. With validation turned off, we see storeUpdatedEditorValue() being called which in turn calls getEditDisplayValues() which returns all 800+ properties on the record. Does the framework need to return all 800 properties when editByCell is enabled and only one cell has been edited? We are considering a patch to only evaluate fields that are visible and/or fields that are editable to avoid processing so many loops that are doing nothing.

    3. When validation is turned on, even though we have editByCell turned on, it looks like the changeEditCell() method is firing and calling validateRow() which also makes expensive calls to validateRecord() which calls storeUpdatedEditorValue() . Shouldn't it call validateCell() if editByCell is turned on?


    Sorry for the dense questions but this is extremely time consuming on our part to try to sort through framework code to find performance bottlenecks. Let me know what else I can do to help sort through how to speed this up for our use case.

    #2
    Hi, for the time being, we are setting allowEditFormValueManipulation=false for our grid and that seems to bypass most of the performance issues that are originating from storeUpdatedEditorValue(). I see that is an undocumented flag but it resolves our issue for now. Is that a safe modification for us?

    Comment


      #3
      We're considering optimizations to the routines you mentioned in your original post but it won't be an instant fix as in the process we'll need to verify that existing use cases still work and make any needed adjustments. We'll update this thread when something's been committed.

      You've changed directions a bit in your second post, so we'll have to evaluate that separately.

      Comment


        #4
        Hi, thank you for the update. Just to clarify, my second post was meant to highlight that most of the issues I pointed out in my first post seem related to performance bottlenecks in storeUpdatedEditorValue() and setting that allowEditFormValueManipulation=false is an effective workaround for the time being. Can you comment on whether setting that flag (which appears to be undocumented) will cause any issues for us in the meantime?

        Comment


          #5
          We're still deciding whether to expose that flag, but the impact of turning it off is that changes made to the edit values of a record other than through the UI and ListGrid APIs such as setEditValue() would not be saved. So, for example, if you had a change handler on one edit item that modified the value of another through the form APIs, that wouldn't be saved with the flag false.

          Comment


            #6
            Hi there, just curious if you have any ETA on when these proposed optimizations may make into the framework? I also wanted to clarify that we also see the same performance issues with editByCell:false so hopefully any enhancements you make will improve performance then. Typically only 10-15 fields will be opened for editing so hopefully there is some way to avoid looping over all 800 properties on the datasource excessively.

            Comment


              #7
              Earlier you indicated that configuring the undocumented property you found was an "effective workaround." Is that not proving to be true?

              Comment


                #8
                That workaround helped some but it is still really slow so I was hoping that you were still investigating potential optimizations you mentioned. If I need to provide more details, I can. Please let me know. I also see significant slowness when executing cancelEditing() and discardAllEdits() to shut down editing on this grid as well.

                Comment


                  #9
                  We can try to replicate your situation by building a sample from the first paragraph of your first post, but you may want to provide us with some standalone sample code to make sure we see the correct performance impact of various internal improvements.

                  Comment

                  Working...
                  X