Poor Performace using the Edge Browser with Virtual Scrolling

[wizarrc]

I'm submitting a ... (check one with "x")

[x ] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here

Current behavior
Chrome Browser - Scrolls like "butter" and fills in rows before visually displayed on demo page
Edge Browser - When scrolling fast, takes approximately 500ms to populate the page with rows. It shows only whitespace indicating that it's taking much longer to render rows.

Expected behavior
Scrolls like butter as demoed using the Chrome browser.

Reproduction of the problem
Go to the demo page, and select Basic\10k Rows using the Edge browser on the Anniversary Update version of Windows 10 and scroll very rapidly. Clicking and dragging the side scrollbar makes this performance issue obvious.

What is the motivation / use case for changing the behavior?
Improve the user experience.

Please tell us about your environment:
Windows 10 Anniversary Update, Microsoft EdgeHTML 14.14393, Surface Book i7

• Table version: 0.7.x
  N/A

• Angular version: 2.0.x
  N/A

• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]
  Edge

• Language: [all | TypeScript X.X | ES6/7 | ES5]
  N/A

Closing thoughts to this matter
I remember hearing somewhere that the Edge browser pre-compiles the webpage and JavaScript prior to displaying the content instead of interpreting the content directly. Might it be possible that the virtual DOM is being recompiled each scroll event causing severe performance degradation? I'm not sure if this is directly related to the project or is a unique use-case that is being mishandled by the browser itself and should be reported directly to Microsoft.

[amcdnl]

Are you running locally or demo page? Locally with ng debugging on it is slow :(

[wizarrc]

I haven't even started using it in my own project. I only visited the demo page that you are hosting without any debugging enabled, and the performance using edge is sub par compared to chrome. This is stock browsers without debug tools open. I would like to incorporate the package into a UWP app (Windows Store App) as part of a webview, which is powered by the Edge browser.

[amcdnl]

@wizarrc can u confirm if this is still occurring?

[wizarrc]

@amcdnl yes, I noticed you have updated your demo page to use version 8.0. I'm seeing the same issue. I also noticed that in addition to perf issues with edge. All browsers seem to be using an obscene amount of memory and cpu with every scroll, even after forcing a gc (chrome dev tools).

I've done some debugging into the root cause. I haven't quite found the exact point, but I think the perf issues are related to the angular template compiler being kicked off every redraw. Instead of just merely reusing most of the containers, it is throwing away everything and recompiling every scroll. The difference is that chrome seems to do it faster than Edge.

I am pretty certain that #464 is related. It is not solved and should be reopened. You can test yourself on chrome if you like. Just open the demo page and look at memory usage as you scroll the 10k list. Try even forcing a garbage collection using the dev tools. I would expect it to go down to the starting point but it rapidly moves the usage up. It looks like it still manages to keep references to the old templates, and those templates keep references to the older ones, and so on. I've managed to open up a test project myself to try to debug the angular source code with a simple example. I will update you when I find something.

[555ea]

@wizarrc Are there any updates on this?

I'm still having poor performance using the Edge with Virtual Scrolling even on a demo page.

[mateBe95]

bump the same problem

[joeveiga]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.