Bad performance using FlexGrid in an Angular App

Bad performance using FlexGrid in an Angular App

Posted by: erik.kleiss on 27 August 2019, 2:29 am EST

• 

  erik.kleiss

  • Post Options:
  • Link
    Copy

  Posted 27 August 2019, 2:29 am EST

  Hello,
  
  we have been using ComponentOne in our .Net Environment for several years and are currently in the process of moving some of it into the web using Angular/Typescript and Wijmo.

  While evaluating the usage of your grid components in our project we ran into some significant performance problems when using the template mechanism for angular to customize the style of our cells. We have built a demo project where the problem can be reproduced. The resizing of the window or the column-header width is really slow.
  
  The profiler shows us that there are way too many render calls in wijmo when you start changing the size. About 100-1000 per second.

  It looks like the performance gets worse as the app becomes more complex. In a very simple scenario, with just one grid and nothing besides, the performance is okay.
  
  But in our real life project the performance is getting worse pretty fast.

  In the demo-project we tried to simulate a more complex situation - making use of *ngIf directives with some simple expressions.
  
  This does not seem to be a particular problem with the usage of ng-template. We think there is a general problem with the triggering of rendering calls.

  Maybe as a hint for you: The performance takes a huge hit when we specify the [cellType] = “‘Cell’” on the ng-template.
  
  Tests were made with Chrome Version 76.0.3809.100 (64-Bit) and Firefox Version 68.0.2 (64-Bit).
  
  The resizing of the window in Firefox does trigger significantly fewer render calls than it does in Chrome.

  Our current hotfix for the problem uses the flexGrid.invalidate(false) call. This call will partially reduce the amount of render calls. This creates some other smaller problems but these are not as annoying as the low performance on resizing. But this at least seems to indicate that it is in fact possible to somewhat control these large amount of unnecessary render calls within wijmo?

  onResize(event: any) {
  
  if (this.flexGrid) this.flexGrid.invalidate(false);
  
  }

  wijmo-lag-sample.zip

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 28 August 2019, 12:19 am EST

  Hi Erik,

  This is expected behavior because of the large number of cells shown in the DOM due to a large number of rows and columns. But, there are a couple of ways by which you may increase the performance:

  1. Use the production mode of Angular:
  
  In development mode, the change detection runs twice for every change, but in production mode, change detection runs only once, thereby increasing the performance.

  2. Use Paging:
  
  If you apply paging to the FlexGrid, the number of cells shown on the DOM will be less and performance will increase. Please refer to the link below that demonstrates how to implement paging in FlexGrid:

  https://www.grapecity.com/wijmo/demos/Grid/PagingScrolling/Client-sidePaging/angular

  3. Reduce the dimensions of the grid:
  
  You may also reduce the width and height of the grid using CSS to decrease the number of cells shown on the DOM:

  .wj-flexgrid {
  	width: 500px;
  	height: 500px;
  }
  

  4. Use formatItem or CellFactory instead of CellTemplates:
  
  Using the formatItem event or CellFactory to customize the cells results in better performance than using cell templates.
  
  Please refer to the links below demonstrating how to use itemFormatter and custom CellFactory:

  • "* “Format Item event: https://www.grapecity.com/wijmo/demos/Grid/CustomCells/ConditionalStyling/angular”
  • “Custom CellFactory: "
    
    https://demos.wijmo.com/5/SampleExplorer/SampleExplorer/Sample/CellFactory”

  Let me know if you have any additional queries.

  Regards,
  
  Ashwin

• 

  erik.kleiss

  • Post Options:
  • Link
    Copy

  Posted 29 August 2019, 9:59 am EST - Updated 3 October 2022, 7:29 pm EST

  Hey,
  
  thank you for the response.

  Step 1-3 are already in use.
  
  Step 4 would pretty much kills the reason we chose wijmo as a tool in our software.

  Still this somewhat misses the point of the initial problem description. We are experiencing massive amounts of cell-redraws that are not needed. We are not talking about a duplication (as in production vs test) but a 10x to 50x increase.

  In our example (simple view no Template/Celltype) with just a grid of 20x10 we will have a content-checked counter of 5 in Firefox but 240 for Chrome (50x increase).
  
  (See comparison pictures. Same in private/incognito windows.)

  • When resizing the window and grid for 1-2 seconds the content-checked counter will increase to ~100 on Firefox and ~2000 on Chrome.

  • When only resizing the window (grid completely visible) the counter will only in crease on Firefox and not on Chrome.

  • If we use the maximixe/unmaximized button of the browser with the grid completely visible the counter will only go up a few points

  • If we use the maximixe/unmaximized button of the browser and the grid is only partially visible the content-checked counter will only increase from 5 to ~10 on Firefox. But on chrome we will go from ~200 to ~700. This results in huge performance drops in Chrome.

  • (When resizing a single row both Firefox and Chrome show a large amount of content-checked calls.)

  Furthermore the use of this code seems to greatly reduce the amount of unnecessary redraws. But it is not fixing the problem from above.

  
  onResize(event: any) {
  if (this.flexGrid) this.flexGrid.invalidate(false);
  }
  
  

  As far as we understand the code calling .invalidate() will reset a timeout within wijmo that keeps the change-detection from running instantly.

  Thanks

  

  1315×926 63.7 KB

  

  1310×906 58.6 KB

• 

  ashwin.saxena

  

  • Post Options:
  • Link
    Copy

  Posted 30 August 2019, 1:07 am EST

  Hi Erik,

  We have asked the dev team to look into this issue. The internal tracking id of the case is 396127. We will give you an update as soon as we hear from them.

  ~regards