Poor column drag performance with table sidebar open

[dsmmcken]

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

Versions

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

[mattrunyon]

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]

yes, that assessment seems correct

[dsmmcken]

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

[dsmmcken]

Should probably limit the size of this placeholder.

[dsmmcken]

This might partly be dndkit performance:

clauderic/dnd-kit#1194 (comment)

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).