SmartClient Version: v10.0p_2015-01-20/LGPL Development Only (built 2015-01-20)
Browser: IE11
Our application is experiencing performance issues when updating grids. I've attached some sample code that can be used to see the issue.
Background:
Our app has a large data set (example demos with 20,000 rows and a little over 30 columns).
Datasource is a custom one that is being maintained locally in the client. This is because we have to keep re-applying the filter on a regular basis because the filter is based upon "now" (which is continually changing). Re-querying the server for the entire data set frequently to account for this is too slow.
The grid as new records added and existing records updated on a high frequency basis because of events sent from the server to the client based upon user actions. We can expect to get 100's of updates a minute during peak periods.
Our grids have filters and sorts applied to them.
What's been happening:
What we've observed is that as the number of records in the data set grows, the slower the adds and updates become. During these updates the browser locks up and becomes completely non-responsive until all of the events have been processed. Since new events are coming in faster than the updates can be processed, this locks up the browser for periods exceeding 30 minutes (until the event load slows down).
We tried queuing up multiple updates and then applying a small batch of them at once, but that just caused the UI to get a little time and then every time we applied a batch it would lock up for periods exceeding 15 seconds (applying a maximum of 10 updates). It also makes it take a lot longer before all updates actually show up in the UI. It seems like it might be faster if we could do bulk adds/updates to the data source, but the add/update methods only take a single record.
About the sample:
The sample tries to match what our application is doing in a simplified form (it is not exact - for example we have some columns with custom cell formatters on them).
We compiled the sample and executed in production mode (not dev mode, it is much slower in dev mode).
If you run the example code, the slowness can most easily be observed by either hitting the "Add 50" button, or selecting a block of records (I would recommend not selecting more than 25) and hitting the "Update status" button.
You can visually see the browser lock up by moving the mouse up and down over the records in the grid. While the browser is locked up, the mouse movement will do nothing. Once the browser frees up, the hover highlighting in the grid will track with the mouse movement again.
Isolating the issue:
In the sample code, we've tried removing the sorting and filtering from the grid. When we do this the lockup time is dramatically reduced (probably in the acceptable range for our application). When we add the filter back in the performance is still pretty good. However, as soon as we turn the sort back on the performance suffers again.
So, the problem appears to be tied to adding/updating a record when the grid is sorted. It seems like adding/updating a record ought to be able to find the correct record location pretty quickly and it should not take that much extra time just because the grid is sorted. Especially in the update case where the field being changed is not even the one being sorted on so that the record is already in the correct location. Seems in this case, a simple test that the record sort is >= the previous record and <= the next record would be a quick test that the record doesn't even need to be moved.
Question:
Is there anything we can do to improve the performance of the adds/updates in this case? If not, is there anything you can do to help?
Browser: IE11
Our application is experiencing performance issues when updating grids. I've attached some sample code that can be used to see the issue.
Background:
Our app has a large data set (example demos with 20,000 rows and a little over 30 columns).
Datasource is a custom one that is being maintained locally in the client. This is because we have to keep re-applying the filter on a regular basis because the filter is based upon "now" (which is continually changing). Re-querying the server for the entire data set frequently to account for this is too slow.
The grid as new records added and existing records updated on a high frequency basis because of events sent from the server to the client based upon user actions. We can expect to get 100's of updates a minute during peak periods.
Our grids have filters and sorts applied to them.
What's been happening:
What we've observed is that as the number of records in the data set grows, the slower the adds and updates become. During these updates the browser locks up and becomes completely non-responsive until all of the events have been processed. Since new events are coming in faster than the updates can be processed, this locks up the browser for periods exceeding 30 minutes (until the event load slows down).
We tried queuing up multiple updates and then applying a small batch of them at once, but that just caused the UI to get a little time and then every time we applied a batch it would lock up for periods exceeding 15 seconds (applying a maximum of 10 updates). It also makes it take a lot longer before all updates actually show up in the UI. It seems like it might be faster if we could do bulk adds/updates to the data source, but the add/update methods only take a single record.
About the sample:
The sample tries to match what our application is doing in a simplified form (it is not exact - for example we have some columns with custom cell formatters on them).
We compiled the sample and executed in production mode (not dev mode, it is much slower in dev mode).
If you run the example code, the slowness can most easily be observed by either hitting the "Add 50" button, or selecting a block of records (I would recommend not selecting more than 25) and hitting the "Update status" button.
You can visually see the browser lock up by moving the mouse up and down over the records in the grid. While the browser is locked up, the mouse movement will do nothing. Once the browser frees up, the hover highlighting in the grid will track with the mouse movement again.
Isolating the issue:
In the sample code, we've tried removing the sorting and filtering from the grid. When we do this the lockup time is dramatically reduced (probably in the acceptable range for our application). When we add the filter back in the performance is still pretty good. However, as soon as we turn the sort back on the performance suffers again.
So, the problem appears to be tied to adding/updating a record when the grid is sorted. It seems like adding/updating a record ought to be able to find the correct record location pretty quickly and it should not take that much extra time just because the grid is sorted. Especially in the update case where the field being changed is not even the one being sorted on so that the record is already in the correct location. Seems in this case, a simple test that the record sort is >= the previous record and <= the next record would be a quick test that the record doesn't even need to be moved.
Question:
Is there anything we can do to improve the performance of the adds/updates in this case? If not, is there anything you can do to help?