Opened 5 years ago

Closed 4 years ago

#1971 closed defect (done)

Adding and removing multiple items in the ItemCollectionView<T> takes too long

Reported by: sforsten Owned by: gkronber
Priority: medium Milestone: HeuristicLab 3.3.10
Component: Core.Views Version: 3.3.7
Keywords: Cc:

Description

Similar to ticket #1963, it takes to long to add and remove multiple items in the ItemCollectionView<T> and in its derived views (e.g. CheckedItemListView, ClassificationEnsembleSolutionModelView.ModelsView, RegressionEnsembleSolutionModelView.ModelsView) and in views where the IItemCollection<T> is used (e.g. RunCollectionView).

The reason is, that the interface IItemCollection<T> is used to add and remove items. It only contains methods to add/remove one item at a time, although the concrete classes like ItemCollection<T> contain methods to add/remove a range of items, which would decrease the runtime drastically.

Change History (15)

comment:1 Changed 4 years ago by mkommend

  • Owner changed from sforsten to architects
  • Status changed from new to assigned

comment:2 follow-up: Changed 4 years ago by gkronber

  • Owner changed from architects to mkommend

Add missing methods to the interface.

comment:3 in reply to: ↑ 2 Changed 4 years ago by mkommend

  • Milestone changed from HeuristicLab 3.3.x Backlog to HeuristicLab 3.3.9

Replying to gkronber:

Add missing methods to the interface.

It is not possible to add the methods for batch manipulation, because all ReadOnlyCollections and Set classes derive from IItemCollection and batch updates are not easily defined for them.

Another solution would be to add a check for the concrete class and call the appropriate methods directly.

comment:4 Changed 4 years ago by mkommend

  • Owner changed from mkommend to gkronber
  • Status changed from assigned to reviewing

r9613: Adapted ItemCollectionView and RunCollectionView to use batch events if the content supports them.

comment:5 Changed 4 years ago by gkronber

  • Owner changed from gkronber to mkommend
  • Status changed from reviewing to readytorelease

Reviewed and tested r9613.

Last edited 4 years ago by mkommend (previous) (diff)

comment:6 follow-up: Changed 4 years ago by gkronber

  • Status changed from readytorelease to reviewing

I found that similar code also exists for instance in ItemListView. Is it useful to make the same change in all views that support AddRange/RemoveRange?

comment:7 in reply to: ↑ 6 Changed 4 years ago by mkommend

Replying to gkronber:

I found that similar code also exists for instance in ItemListView. Is it useful to make the same change in all views that support AddRange/RemoveRange?

Yes, the ItemsListView should also be adapted. However, I found another issue, which I don't know how to resolve correctly. If a collection contains duplicate items, currently the first reference to it is removed, regardless of the selection. So the question is how to deal with duplicates in collections (not only regarding deletion)?

The deletion is handled in a better way in ListViews, because there the items are removed according to their index and so duplicates are no issue.

Last edited 4 years ago by gkronber (previous) (diff)

comment:8 Changed 4 years ago by mkommend

  • Owner changed from mkommend to gkronber
  • Status changed from reviewing to assigned

comment:9 Changed 4 years ago by gkronber

  • Owner changed from gkronber to mkommend

We should leave it as it is. The first occurrence of an item should be removed when an item is contained multiple times in a collection.

comment:10 Changed 4 years ago by mkommend

  • Owner changed from mkommend to gkronber

Currently the ItemListView performs GUI-triggered modifications based on the index of the item. This is not possible when using batch modification commands => The behavior of the ItemListView would be changed. Therefore, I disapprove using batch commands in the ItemsListView.

comment:11 Changed 4 years ago by ascheibe

  • Milestone changed from HeuristicLab 3.3.9 to HeuristicLab 3.3.10

comment:12 Changed 4 years ago by gkronber

  • Owner changed from gkronber to mkommend
  • Status changed from assigned to reviewing

r10495: used the more general type ObservableCollection in ItemCollectionView. In RunCollectionView the type must be RunCollection.

As discussed with mko and sketched in comment:10 we won't change ItemListView.

comment:13 Changed 4 years ago by mkommend

  • Owner changed from mkommend to gkronber
  • Status changed from reviewing to readytorelease

comment:14 Changed 4 years ago by gkronber

r10529: merged r9613 and r10495 from trunk into stable.

comment:15 Changed 4 years ago by gkronber

  • Resolution set to done
  • Status changed from readytorelease to closed
Note: See TracTickets for help on using tickets.