Poor performance of startEditing/endEditing FlexGrid handlers

Poor performance of startEditing/endEditing FlexGrid handlers

Posted by: hvo986 on 14 September 2017, 11:49 am EST

• 

  hvo986

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  Hi.

  Recently we faced an issue when our FlexGrid instance used in Angular 1.5 application becomes unresponsive for a second when cell enters or exits edit mode. Profiling shows that a lot of time is spent on

  refresh

  method invoked from

  _EditHandler.startEditing

  and

  _EditHandler.finishEditing

  handlers. Also we found that this

  refresh

  method completely removes ALL cells from the DOM and then renders them again. This process takes time, as we use custom cell templates in our grid. Taking into account that in average we have 10-15 columns and 20-30 rows in visible area of the grid, it disposes and renders from scratch 200-450 cells every time cell editor is displayed or removed.
  
  And this seems not very optimal, as visually just one cell changes (well, sometimes two when we have row header), all other cells remain the same (both text and css).

  So the main question: how can we avoid complete re-rendering of the whole grid when cell enters and exits edit mode and refresh only cells that are affected by these events?

  Of course when cell editing is finished, we might need to refresh the whole row, as there can be computed cells that depend on updated cell, but rendering one row will be ~20 times faster than rendering 20 rows.

  Thank you.

• 

  hvo986

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  Hi.

  Could you please let me know if this can or cannot be solved? Any information is much appreciated.

  Thank you.

• 

  nsd

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  @hvo986 We have been seeing the same issue, best solution that we have so far is:

  • Limit the amount of content we display in “viewmode”
  • Use setTimeout to set the text of cell after the rendering is completed (this is difficult)
  • Replace custom cell with lots of elements with an server rendered image instead.
• 

  bernardo

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  We are working on this and expect to include this optimization in the next maintenance build (237+).

  Thank you very much for bringing this up and helping us improve our products!

• 

  hvo986

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  @nsd, thank you for sharing your solution. We also reduced the number of simple templates (which only add cell styling or basic value formatting) by using

  itemFormatter

  callback. While it’s faster, it’s not as convenient as specifying appearance options in cell templates. But in this case performance is more important for us. Thank you!

  @bernardo, thank you for the good news! Looking forward to test the new build!

• 

  bernardo

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  Hello again.

  This time I have not-so-good news. We did implement this optimization but found there are too many edge cases/exceptions, including frozen cells, merged cells, header/footer cells, and aggregates. The “optimized” version ended up so ugly and clumsy we decided to scrap it and see if we can come up with an alternate approach.

  Sorry for raising expectations to soon. The optimized version looked really good at first…

  We will continue researching this, but it probably won’t make it into the next maintenance build. Sorry.

  In most cases re-creating all visible cells is so quick that this issue should not be a big one, but I can imagine there are exceptions. Cell templates are the most probable case, but they depend on application frameworks as well as Wijmo. I assume you are using either Angular 1 or 2?

  If any of you guys could share a sample project to illustrate, that would be really useful to us.

• 

  hvo986

  • Post Options:
  • Link
    Copy

  Posted 14 September 2017, 11:49 am EST

  Well. Thank you for the honest answer.

  We still use Angular 1.5.5 and I doubt we’ll be able to switch to Angular 2 in the nearest couple months, so we try to solve performance issues with what we have. Unfortunately I didn’t have time to make sample project demonstrating the issue, but I hope I’ll be able to do that soon.

  And talking about Angular 2 - does FlexGrid with custom templates performs significantly faster in Angular 2? (I’ll be surprised if it doesn’t

• 

  johnny.su

  • Post Options:
  • Link
    Copy

  Posted 24 July 2018, 7:48 pm EST

  We’re also having the same issue with lots of custom cells. Any updates on a potential optimization fix and/or tips-and-tricks?