Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/bootstrap-vue/bootstrap-vue/issues/4155 below:

Performance drops whenever more than a few thousand cells are rendered · Issue #4155 · bootstrap-vue/bootstrap-vue · GitHub

When attempting to render more than a few thousand cells in b-table, rendering performance and general vue performance seem to drop off quite noticeably resulting in a poor user experience.

1. Create a b-table that renders at least 100 records of data with at least 10 columns of data.
2. After the table renders the records, vue processing performance appears to be degraded significantly (e.g. other bound input controls on the component hosting b-table).
3. There is a very noticeable lag between when the provider returns the data array and when the refreshed event for b-table fires.
4. There is also a noticeable lag between when the refreshed event for b-table fires and when the actual table appears to be fully rendered with the new data.
5. The more times the provider returns data, the worse performance seems to get.

1. b-table should render cells quicker than the half a second it currently takes in Chrome with 500 rows and 13 cells my example runs for.
2. Lag between refreshed event being fired and b-table completing its rendering process should be reduced.
3. Vue processing performance for other bound input controls in the same hosting component should be non-existent.
4. Subsequent calls to the provider should not degrade performance in any way.

Libraries:

• BootstrapVue: 2.0.2
• Bootstrap: 4.3.1
• Vue: 2.6.10

Environment:

• Device: Intel x86 Laptop and Desktop
• OS: Linux and Windows
• Browser: Chrome and Firefox
• Version: Latest

https://jsfiddle.net/ke3f2whb/1/

Demo allows user to modify row count using bound text box. Default row count is set to 500. Column count is set to 13.

This was not an issue in 2.0.0rc26 but is definitely an issue in 2.0.0, 2.0.1 and 2.0.2. I can't speak for in-between versions as I have not personally tested them. This appears to be a rather severe performance regression and is currently hindering a number of user activities in a production application of mine (yeah, they really wanted floating headers).

In addition this problems also appears to severely degrade route switching performance when the user does something that results in a route change and the current view includes a b-table component with a significant number of rows.

For the time being, I have restricted the maximum number of rows per page in the application to 100, which helps a great deal but when it comes to tables with a larger number of columns, performance is still a problem. Any fixes or assistance you can offer would be most appreciated as my users are putting a lot of pressure on me to resolve the issue.

WillGoldstein, adammoss, Hiws, fuzzytoe, krzysztofjeziorny and 1 more

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4