Ag-Grid Performance Optimization, Memory Usage and Speed/Slowness Considerations for Enterprise — Embedded, Electron, Chromium

Managing expectations and adjusting your use cases for the web is the most solid advice I can give after using AG-Grid in enterprise applications, under many different deployment scenarios (plain data & streamed).

Published in

The Startup

5 min readJun 1, 2020

I will go through a few topics in very few words, all of them being things I was not able to find much information on during my research on using AG-Grid as effectively as possible and dealing with the different blockers.

Disclaimer: These tests have been done with Angular 7 and 8. I think the conclusions will remain relevant even for Angular 10.

Using AG-Grid within existing .NET applications

While certainly an option that removes memory limitations imposed by some browsers and allows you to smoothly adopt web technologies without having to split the user experience between two apps, it at the same time (even with the best libraries out there: CefSharp, …) has the likely hood of breaking the performance of certain parts of a JS app and additionally lead to unexpected behavior of some of the CSS and otherwise default functionality (JS prompts, global CSS, context menus, downloads, copy-paste) which might result in dev-work related to supporting the embedded context only.

This depends on which versions of the library you will be using (of which you might be limited to a specific subset), but it is unlikely you will not be facing a downgrade in the richness of experience while gaining on the memory front.

Once the data is successfully loaded in the grid, the behavior of general features seems to be comparable to running in Chrome but without memory limitations.

I’ve not found an official benchmark from CefSharp.

If you like this content, check out my article on How To Not Be a Run-of-the-Mill Software Engineer.

Browsers Memory limitations

Even on 64-bit, Chrome caps your tab RAM usage. Other browsers might be better at this (e.g. the new Edge), for example, I have not found characteristics on whether Firefox has such inherent limitations (surface R&D seems to suggest it might not be a problem in there, however it was not an option for us). Be prepared to invest in streaming and generally re-assess your use cases if previously you were under high memory availability.

While development will be easier and UX better (and more future proof for PWAs and a consistent experience to what your users, via a browser), the memory cap might become a blocker until the initial cost of re-architecting is spent. Sometimes using a different browser is not a valid option.

Take advantage of the tabs as much as possible to split the data between tabs as drill-throughs or just different granularity windows into the data.

Electron/chromium shells

These are good options that, just as embedding in a .NET app, remove the memory limitation.

However, you would be taking away the it-all-works-in-a-browser experience and goal, in which the assumption would be your app can work on a tablet, mobile phone, or indeed any medium if it is a web app.

For a very quick solution, Electron and co would rapidly remove the memory limit (and give you access to native API) but ensure it is the strategic move for you before deploying to production.

Keep in mind however that there may be things it is not ideal at if not used correctly or if these aspects are not taken into account for the long-term.

Optimizing your usage of AG-Grid

There are not very many hints on how to approach this. We have noticed as soon as things like row-group totals are enabled, the performance degrades considerably (use-case of 150+ columns with hundreds of thousands of rows).

I think your best bet is to limit your use of features according to the row/column/data count, disabling/enabling them on a per-need basis. If your data is always large and there is no simple way to work around that issue, streaming would likely be the only option, alongside using something that adds no additional strain like Electron.

Another solution is to load the data in memory but not in AG-Grid. It will use less memory while it’s not in AG-Grid, as such feed it to the grid API on a drill-through behavior pattern basis, driven by user action. Even parsing your strings as a number or introducing any small feature will have a big performance impact when dealing with enough rows and columns.

And virtualization is not the issue, as the grid functions seem to work correctly and quite smoothly, but the memory usage surge will kill your tabs in no time if you don’t expect and benchmark for it.

TL;DR

You should feed as little data as possible to the UI to enjoy in full the richness provided by a web user interface. A move to the web is not guaranteed to tick all your existing boxes plus some on top, not without re-architecture of the way you deploy data to the UI.

Dear Reader,

Please clap, follow and join my newsletter if you like this content and you would like to support 🙇🏻‍♂️. You can connect with me on X (Twitter), Linkedin, Instagram & Github, and find out more on nenuadrian.com!

If you liked this article, you may also enjoy: