0

Background

I have a data table in an ASP.NET Web Application. This table is contained within an UpdatePanel. When I run a query that generates a large amount of data (5,000 rows and ~20 columns), this table takes a very long time to update, but only in Chromium browsers. By "very long", I mean ~30 seconds. In Firefox, the table takes maybe ~5 seconds to update, most of that time is spent waiting for the server to retrieve, process, and send the data to the client. Additionally, the Chrome tab uses ~1.1GB of memory and the Firefox one uses ~650MB.

There is an additional query which expands the view to ~45 columns. When running this, Chromium browsers take ~2 minutes to process this and most of the time fail with an Out of Memory issue, reaching ~3.9GB for the tab before the browser kills the process. Firefox again takes maybe ~7 seconds to update for this case, and uses significantly less memory (~800MB) to do so.

Debugging with Chrome's tools, I narrowed the problem down to a single long-running call in MicrosoftAjaxWebForm.js. The call is:

updatePanelElement.innerHTML = rendering;

updatePanelElement is my ASP UpdatePanel, and rendering is a string representing the HTML for the new table data in its entirety. The length of this string for an example query is 21752850 (~21MB).

What I Have Tried

After some initial searches, I came to suspect that Hardware Acceleration may not be being used in Chrome for this task, as mentioned in this answer, it appears Chrome may not always use it, so I tried adding transform: translate3d(0, 0, 0); to the CSS for my table. This had no effect.

After this, I tried parsing the DOM of the new table data separately, initially using DOMParser as suggested in answers here, then using createContextualFragment as suggested in answers here. In both cases, the calls to actually parse the DOM were fast (easily less than half a second) in both browsers, but when attempting to append the newly parsed nodes using updatePanelElement.appendChild(frag); where frag is the DocumentFragment created by createContextualFragment, the update was still as slow as before in Chromium browsers. Firefox remained just as fast as before.

Has anyone else encountered this issue? Does anyone have any suggestions as to why Chrome is so much slower with this large update than Firefox is? I am aware that having a single table containing ~21MB of data isn't ideal, but for now it's not possible to paginate it and clearly it is possible to render this quickly, as Firefox manages fine. Finally, is anyone able to suggest a solution, or any other techniques I could try?

madmonk46
  • 421
  • 3
  • 10
  • 1
    You can try implementing [createHTMLDocument](https://developer.mozilla.org/en-US/docs/Web/API/DOMImplementation/createHTMLDocument) to render the HTML before inserting it in the DOM. However it is still better to implement pagination or some kind of data streaming so you don't have to download so much data at once, which is beneficial for mobile users. – Reyno Mar 01 '23 at 10:19
  • 1
    *"This table is contained within an `UpdatePanel`"* - \*scratch head\*, perhaps it is time to move to newer tech and use plain ajax with json or something. asp.net's `UpdatePanel` sends whole table through ajax which causes tons of dom changes involved. also, this problem seems to exists [since ages ago](https://stackoverflow.com/questions/22475990) which surprising despite people claim saying "chrome faster than firefox." – Bagus Tesa Mar 01 '23 at 10:19
  • @BagusTesa I had noticed that most of the posts historically related to Firefox being slower, which I thought was strange. Longer-term, I'm certainly hoping to move to a newer framework and a generally better solution overall. – madmonk46 Mar 01 '23 at 10:34
  • @Reyno I'll take a look at that, thank you. If I find a solution, I'll post it as an answer – madmonk46 Mar 01 '23 at 10:34
  • hand coding some jQuery and pulling jason not going to by "magic" run faster than a simple update panel here - but, you will write a boatload of extra code, and rack up MUCH higher development costs (ignore the clown suggestions here that some update panel is the problem here. The REAL problem is attempting to pull 5,000 rows of data to the browser. You might be on a GREAT connection, but users at Joe's truck stop with 20 other people sharing that wi-fi connection will NOT have such great performance. Bottom line: you can't possible need to pull 5,000 rows of data - page that data. – Albert D. Kallal Mar 01 '23 at 17:41
  • While I am aware that this isn't the optimal solution (a point I did make clear in the original question), there are factors relevant to this implementaion that mitigate some of the issues with this approach. I can guarantee that everyone that uses this site has an excellent connection to it, for example. At any rate, it clearly is possible to do this with reasonable performance, Firefox is already doing it. It would be useful, not to mention just plain interesting, to know why the two differ and what in the code might be causing it. – madmonk46 Mar 01 '23 at 18:21

0 Answers0