SVN 13025: use the ListBox's RemoveAt implementation if <= 100 items are selected. Testing shows that is quicker for long (>500) lists. Further profiling could show the breakeven point for other scenarios, but this must cover the commonest ones.

SVN 13026: replace slow LINQ functions with a simple loop to calculate the longest article name. Still to do: keep a running updated in a subclass of ListBox's ObjectCollection. Improvements between 4x and 6x on very long lists.

SVN 13027: use BeginUpdate to easily prevent flashing when a large number of ReplaceSpecial rules are pasted into the tree. Still to do: prevent the rule detail page flashing too.

Further info on rev 13026 / lbArticles_DrawItem change: my benchmarks (20k items):

existing lbArticles.Items.Cast<Article>().Select(ar => ar.Name).ToList().OrderByDescending(s => s.Length).First(); takes about 18 ms total for one 20k article paste.
The new foreach takes about 2 ms for same. So I agree clearly faster.

Probably the OrderByDescending is the slow bit. An alternative lbArticles.Items.Cast<Article>().Aggregate((max, cur) => max.Name.Length > cur.Name.Length ? max : cur).Name; also takes about 2 ms for same. At the level of ms no different to foreach. Maybe a more detailed profiler can confirm if foreach better than Aggregate?

Agreed the Aggregate method probably uses basically the same logic as the loop but with additional object creation. Having done a lot with LINQ I'm always suspicious these days and want to know what goes in inside, so I'm more inclined to use the C style.

I did try wrapping or subclassing the Listbox.ItemsCollection class, and comparing the name length on every Add, Remove etc. But that turns out to be famously intricate (the Items property has to do double duty) and I gave up. 2 ms is nothing to sneeze at.

Oddly on my benchmarks my ARM Surface is faster than my ancient PC at 20K items, but slower at 100K. Maybe because object references are twice as big.

Observation: every time (almost) that the lbArticles DrawItem method is called when the item count is the same as last time, the identity of the longest article hasn't changed. The exception, deleting that article and adding a shorter one without an intervening draw of the list, is hard to imagine.

Every time the visible part of the list changes and the list is redrawn, the DrawItem method is called 16 times in succession, once for each visible line. Testing a "list is same length" shortcut, DrawItem runs between 2x and 3x faster on average; it only re-scans the list one time in 16. On my (slow) PC with a 20K item list that's a change from 2.2 ms to 0.8 ms per item, times 16 per re-display. 22.4 ms is not really noticeable but not hard to code either, and it's between 6x and 7x faster on a 100K list.

Furthermore, skipping the horizontal bar resize when the longest article is unchanged adds a smidge to the speed.

Finally, there's a bug introduced in 6.4; if you clear the entire list the scrollbar isn't removed (oddly, it gets longer) because the DrawItem code isn't called. I'll enter another bug.