You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sort of a continuation of the issue described in #5115 , whenever a user changes the set of columns that are currently viewable by resizing one, either by expanding a column so that another is pushed out of the table viewport or by shrinking a column so that another comes into view that was not previously, the number of calls to the tabbable library become prohibitively expensive for 50 or 100 rows of data.
Thank you for raising this issue @kqualters-elastic. I would agree that this is a priority as I would expect users to frequently adjust column sizes to account for various field character lengths.
After @chandlerprall 's awesome work with #5163 , I've tested the table again and the difference is night and day
So much so that I no longer think we need to do elastic/kibana#111899 or elastic/kibana#111100 performance is good when using every interaction in EuiDataGrid that I'm aware of, even with 100 rows. @paulewing@XavierM@mchopda what do y'all think?
Sort of a continuation of the issue described in #5115 , whenever a user changes the set of columns that are currently viewable by resizing one, either by expanding a column so that another is pushed out of the table viewport or by shrinking a column so that another comes into view that was not previously, the number of calls to the tabbable library become prohibitively expensive for 50 or 100 rows of data.
A similar flamegraph can be seen on https://elastic.github.io/eui/#/tabular-content/data-grid
The text was updated successfully, but these errors were encountered: