[FlexGrid with Angular] Performance issues caused by massive Angular CDs

Posted by: james.ingham on 31 August 2020, 5:34 pm EST

    • Post Options:
    • Link

    Posted 31 August 2020, 5:34 pm EST

    Dear Support,

    We discovered some serious performance issues when using the angular wrapper of FlexGrid class, which slows down our entire application. Massive Angular change detection cycles are triggered in various situations:

    1. When is firstly loaded, hundres of CD cyles are executed.
    2. When you drag column borders to resize columns, thousands of CD cycles are continuously triggered.
    3. Sorting columns also triggers CDs many times.
    4. Other situations when you update FlexGrid layout.

    I have created a sample to demonstrate this issue:

    https://stackblitz.com/edit/angular-fp3b47

    Note this problem does not exist if we directly call pure javascript APIs (jQuery way):

    
                this.jqueryFlexGrid = new wjcGrid.FlexGrid(document.getElementById('jqueryGrid'), {itemsSource: this.data});
    
    
  • Posted 1 September 2020, 7:22 pm EST

    Hi James,

    The FlexGrid does not fire any unnecessary change detection. All of the change detection is run by angular itself whenever required. But still, we could observe some performance difference in the angular and js FlexGrid. So, we have forwarded this to the developers for further investigation. The internal tracking id of the case is 460597. We will update you once we will hear from them.

    Regards,

    Ashwin

  • Posted 1 September 2020, 10:43 pm EST

    Hi Ashwin,

    Thanks for forwarding this issue. Angular triggers CD when timers are set or any input event (mouse/keyboard etc.) occurs. If Wijmo’s angular wrapper instantiates any FlexGrid instance inside the Angular zone, and FlexGrid class uses setTimeout/Interval or listens to any mouse/keyboard events (I believe it does), then CD will definitely be triggered, unless you specifically wrap them with runOutsideAngular(). This problem can’t be fixed from Wijmo user’s code because Angular instantiates components behind the scenes.

    Please let us know how it goes and we are looking forward to seeing a solution. Thanks for your help!

  • Posted 2 September 2020, 3:04 pm EST

    Hi James,

    Thanks for the updated info. I will forward it to the developers.

    ~regards

  • Posted 16 September 2020, 12:06 am EST

    Hi James,

    The developers have said that the change detection which runs during these operations are expected. According to the provided sample, they observed that the grid was slow due to the console log statements.

    They have also improved the performance of the flexgrid in the last build. So, can you try upgrading your application to the latest version (5.20202.724) and let me know whether the performance is increased or not.

    Also, there can some other reasons why the grid is slow in your original application. Have you applied heavy formatting on the grid? If a large number of cells are displayed on the DOM, then also the performance can be reduced.

    ~regards

  • Posted 17 September 2020, 6:13 pm EST

    Hi Ashwin,

    Thanks for your follow up. I tried the new version 724, which seems much better than 680. It still triggers around 30 CD cyles per second when you drag column boder or do virtual scrolling but it’s acceptable.

    Regarding “According to the provided sample, they observed that the grid was slow due to the console log statements.”, I think they misunderstood the purpose of that sample I provided. The console log was used to show how many CD cycles being triggered. If you see 20 “‘=== test angular CD ===’” messages, it means CD has been triggered 20 times… that’s all.

    Anyway, thanks a lot for your help!

    James

  • Posted 20 September 2020, 3:31 pm EST

    Hi James,

    We are glad that the performance issue was resolved.

    It still triggers around 30 CD cycles per second

    This may be because the drag event fires continuously until we keep dragging the column. Also, while running angular in developement mode, each change detection cycle runs twice, so this number will go down while using production mode.

    I think they misunderstood the purpose of that sample I provided

    Developers investigate the issues according to the samples provided by the customers and they also reply according to the sample. So, if they think that the console log statement may be the reason for the performance issue, then they will suggest to remove these statements.

    ~regards

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels