Improve the performance of run collection event handlers

[abeham]

I have several experiments with a very large number of runs (several thousand per experiment). Even though the runs are only very small (serialized size of one experiment is no more than 10MB) and fitting them into memory is not a big problem, handling these runs is very slow. The good thing is that our analysis views work very well and fast. The box plot analysis is amazingly fast. However, there are several actions that should not take as long as they currently do:

• Selecting the first and shift-selecting the last runs takes about 15 minutes until all runs are selected.
• Copying these runs to a new run collection is also very slow.

I assume the event handlers that are currently implemented in the run collection view do not scale very well to large number of items. Their performance should be improved.

[abeham]

Regarding the selection of multiple runs:

In itemsListView_SelectedIndexChanged the method AdjustListViewColumnSizes is called every time the selected index changed. When multiselecting in the listview this event will be fired for every single item that is selected so in total N times for N selected runs. The only way to explain the really slow performance when multiselecting huge lists is that adjusting the column sizes also needs to iterate over a number of items (probably all) which results in O(N²) performance if all runs are selected. I tested to remove this call which solved the performance problem.

However I couldn't find out about the original problem that should be solved with this change. I looked into the change history: The call to adjust the column sizes was added by swagner in r3829 to implement some reviewer comments. The same call was also added to the other collection views, so there was definitely a problem to be solved. Unfortunately this change is not listed on our review pages. Do you remember which reviewing issue should be solved by this change so that we can find another solution that doesn't reopen the original issue?

[abeham]

Regarding the concatenation of runs in one list:

The problem is similar to the above: The concatenation is implemented to add every single item separately and AdjustListViewColumnSizes is called on every addition. The Content_ItemsAdded event handler is implemented to work with multiple items being added at once, so I think if possible we should call AddRange instead of Add. Unfortunately, this is not possibly in every case since the RunCollectionView is also a view for IItemCollection<IRun> and this interface doesn't contain an AddRange method. Either we include that method somewhere in the interface hierarchy or we have to separate between cases where we deal with a RunCollection and cases where we don't have a RunCollection.

I think in general it would be best to avoid having to call the "inefficient" AutoResize method on list view columns so often. Is there a faster way?

[abeham]

r7065

• Improved the performance of the RunCollectionView when working with larger number of runs

As previously stated I changed the behavior in DragDrop to use the AddRange method which would only call the resizing once for the batch that is dragged in. I also changed SelectedIndexChanged to only resize when the SelectedItemsIndices.Count property is 0 or 1. I didn't found a reason to resize the columns when more items are selected.

I tested this with a collection of about 74,000 runs and it works acceptly fast. There's some delay, but it's certainly good enough to work with. The more items we have, the more we should probably go in direction of changing the listView's behavior to VirtualMode.

[mkommend]

I could not test the implemented improvements with a RunCollection as large as yours, but I reviewed and tested the source changes.