0

In extjs 7.5.1 all gridpanel are "infinity scroll" ones and have the plugin https://docs.sencha.com/extjs/7.5.1/classic/Ext.grid.plugin.BufferedRenderer.html

"(...) users to scroll through thousands of records without the performance penalties of rendering all the records into the DOM at once. (...) It is instantiated automatically and applied to all grids"

I am struggling with a application migration to extjs 7 from an older version. It works as expected in the source extjs 4 version (with same amount of lines ~80k). First step was to remove explicit creation since it is not supposed to be used directly anymore.

This is a private utility class for internal use by the framework. Don't rely on its existence.

What is the best approach to try to troubleshoot what is going on?

In the browser DevTools:

grid.bufferedRenderer.isBufferedRenderer <true

grid.bufferedRenderer.isPlugin <true

grid.bufferedRenderer.disabled <false

grid.bufferedRenderer.id <null

This last one may seem suspect... But if I do a getId() instead it gets an generated Id from that point on.

Given my lack of tim, I am unable to reproduce a example of the code, and I am not allowed to share the real code.

I have a before application (extjs4) and an after(extjs7). So we migrated the version of the extjs for a new version and fixed a lot of broken functionality, most of them had an explicit error and we could track the error to a location in the code (many times in extjs framework code, since it would manifest itself there).

Memory snapshot shows 4GB of ram mostly in DOM objects, so BufferredRenderer is not doing it's job.

I have reviewed the code looking for suspicious overrides or configuration that might have cause conflict with new version of extjs. I have and will try debugging code, but since the issue occurs in extjs side of code, I am taking a lot of time to try figure out what is going on with very little progress. Maybe I will try to stub data to fix volume of lines in a fast to iterate but big enough to check the Dom for the opitmization, hoping 200 lines will suffice.

João
  • 2,296
  • 5
  • 20
  • 30
  • 1
    Do you have an `Ext.data.BufferedStore` behind the grid? I don't think you need extra config on the grid in recent ExtJS versions. You need to have a properly configured store and proxy. – Peter Koltai Feb 28 '23 at 20:50
  • Thank you Peter for your comment. No we do not, we actually loading all data through loaddata method, that would not make sense in a buffered store that assumes partial store allocation as needed. Using a normal Ext.data.Store works good enough loading all store into memory in extjs4, the profiling makes me believe that the issue is not with the memory usage by the store, but in DOM representation of it in the grid rendering objects allocation in memory. – João Mar 01 '23 at 11:14
  • 1
    I see. What I know is that for this amount of data to show in a grid, a buffered store is proposed by the documentation and examples by Sencha. – Peter Koltai Mar 01 '23 at 11:28

1 Answers1

0

We are still trying to understand exactly what happened, but we have found an effective workaround: creating or binding a new store for each search.

I replicated the issue outside of my application with a helper static data file. We are using extsj 7.5.1, and I will try to make a fiddle if I find some free time (not likely).

If I do a dynamic binding using grid.bindStore(store), it effectively shows large amounts of lines; if I use the Ext.grid.Panel store configuration, it doesn't and blows up with an Out of Memory exception. Suspect something regarding a buffered renderer bug. Not sure.

João
  • 2,296
  • 5
  • 20
  • 30