Closed juliusknorr closed 3 months ago
Testing with the firefox performance tool gave some useful insights:
I've tested the rendering of the whole list at once compared to getting the entire list in the store but just rendering the first 100 elements. The handling of the list itself has very little impact as the Rendering Time drastically improved with just 100 Elements. From between 22 to sometimes 30 seconds down to about 1-3 seconds. The Initial Backend request itself has not been calculated in, but takes up some time as well.
Though a lot faster, with just 100 elements rendered, the search filtering is still quite slow.
We can definitely noticeably improve performance on the Frontend side, but in the future customers might get to the limit of what browsers can handle
performance rendering all rows performance rendering first 100 rows
Thanks @grnd-alt How many rows in total did you have in your test scenario? I'd say if we can handle 10k rows reasonably well with virtual scrolling it would be worth to take that as an intermediate step until we figured out how to properly paginate the backend response. I'd say we can accept a slightly longer loading time on the initial request.
We should also take the opportunity to add some documentation for the current state to the readme #448
@juliushaertl I've had a little more than 10k rows. I think virtual scrolling is definitely a good first step. Should I open a PR on #279 ?
Hi! This is a very good incident. I have a table with 189 rows and the data are downloaded in webUI very slowly, and the page freezes. The same with the Android app, which from time to time denies to show data with the error that the connection with the web app is lost.
We should get a better overview on the frontend side to see where the bottlenecks are with 1k, 10k, 100k rows to know what implementation efforts have what impact.