search

deephaven / web-client-ui

Deephaven Web Client UI
Apache License 2.0
29 stars 31 forks source link

Poor column drag performance with table sidebar open #1650

Open dsmmcken opened 11 months ago

dsmmcken commented 11 months ago

Description

Table column drag performance can be really poor to "unusable" when a user has a high number of columns and the table sidebar open. It looks like the sidebar is re-drawing on every single grid render/mouse move.

Steps to reproduce

from deephaven import time_table
cols = []
for i in range(500):
    cols.append("column" + str(i) + " = i")
hundreds_of_cols = time_table("PT1S").update_view(cols).reverse()

Using the above table, open the table side bar and go to the organize columns screen. Click on table column in the table and drag it around.

Expected results

Table remains snappy and responsive while dragging.

Actual results Table is laggy, with frequent pauses that can be greater than 500ms-1000ms. (Which on a ticking table can be near constant).

Additional details and attachments

slow_drag

Versions

Engine Version: 0.31.0 Web UI Version: 0.54.0 Java Version: 21.0.1 Barrage Version: 0.6.0

mattrunyon commented 11 months ago

The issue is when the columns are actually swapped, not on render/move. If you drag slowly without swapping the columns it's fine. We trigger a onMovedColumnsChanged as soon as the drag past happens (not on drop). This triggers a re-render in the visibility menu

dsmmcken commented 11 months ago

yes, that assessment seems correct movechanged

dsmmcken commented 11 months ago

class VisibilityOrderingBuilder extends Component -> PureComponent, which will reduce renders, but it still sucks when columns actually move.

dsmmcken commented 11 months ago

Should probably limit the size of this placeholder. image

dsmmcken commented 11 months ago

This might partly be dndkit performance:

https://github.com/clauderic/dnd-kit/issues/1194#issuecomment-1696704815

From an August issue posted on dnd-kit, they have a refactored experimental branch that should help reduce re-renders. No idea when it will land though, and may not entirely fix it.

Current recommended mitigation is to keep the table drag pending until dropped so it doesn't trigger the list to be re-ordered while it is dragging past each column. Be sure to check that a browser disconnect/exit while dragging doesn't leave you in a broken state after this change (as I believe that was the reason for the current behaviour or committing the drag position immediately).