When sorting, reduce DOM reads

[jpmelos]

Two things to improve performance:

• Reduce the number of times we read from the DOM each time a sort action happens.
• Only read the rows from the DOM the first time we sort. This is possible because lines only change upon a full reload.

[thomasst]

My agent did not measure a meaningful improvement.

Queues	Branch median	Master median
1,000	36 ms	37 ms
5,000	1,243 ms	1,094 ms

Let me take a closer look at this though.

[jpmelos]

This is the best thing my agent could come up with. Claude said browsers do not re-render anything while a JS script runs, so the issue is not that. It also said the sorting algorithm itself is not the problem.

Then it theorized it could be the sheer number of reads from the DOM, because the JS script needs to yield control back to the browser engine to get those reads, and then control is handed back to the JS engine, and this dance (said the agent) can be expensive.

I do not know whether that holds in reality or not, though. Could be completely made up by the agent...

[thomasst]

This is the best thing my agent could come up with.

Then your agent is not very good. I'll push some improvements shortly

[jpmelos]

It's Opus 5.5 with xhigh thinking! What do you use?

[thomasst]

GPT-6 Sol High. Pushed an improvement commit. Here's what it claims (I also tested it, and it is much faster):

The last commit sorts whole queue groups without rearranging their collapsed child rows. It sorts child queues when you expand a group and resorts them if you change the sort while they’re visible. With 5,000 synthetic queues (100 groups of 50), synchronous sorting fell from about 1,094 ms to 24 ms with all groups collapsed, and from 1,154 ms to 63 ms with all groups expanded. These measurements exclude browser paint.

[jpmelos]

Looks good to me! 👍 Shall we merge this?