observablearray splice performance issue

[felixkrautschuk]

Make sure to check the demo app(s) for sample usage

Make sure to check the existing issues in this repository

If the demo apps cannot help and there is no issue for your problem, tell us about it

Please, ensure your title is less than 63 characters long and starts with a capital letter.

We try to replace all RadListViews by CollectionViews but we notice one performance issue only on iOS. In our app the user should be able to select items in the list and delete them and we notice that deleting an item takes much more time with the CollectionView than using a RadListView.

When deleting a single item like this

export function deleteItem(args) {
  const bindingContext = args.object.bindingContext;

  console.time();
  vm.get("items").splice(vm.get("items").indexOf(bindingContext), 1);
  console.timeEnd();
}

we see the following results: CollectionView: 169 ms RadListView: 8 ms

In our real app, we have a lot more items in the list with much more complex layouts, there we see the following results: CollectionView: 2253 ms RadListView: 78 ms

On Android, I get the following results for both apps, no matter how many items are in the list and no matter how complex the layout is: CollectionView: 0.2 ms RadListView: 0.2 ms

Do you have any idea, what is causing the performance difference on iOS?

Which platform(s) does your issue occur on?

• iOS
• 16.2
• emulator and device

Please, provide the following version numbers that your issue occurs with:

• CLI: 8.4.0
• Cross-platform modules: 8.4.7
• Runtime(s): 8.4.1
• Plugin(s): collectionview 4.0.71, nativescript-ui-listview 15.2.0

Please, tell us how to recreate the issue in as much detail as possible.

Just open the sample app provided below, navigate to the CollectionView page and delete an item. Then navigate to the page with RadListView (or ListView), do the same and compare the results.

Is there any code involved?

ns-collectionview.zip

[farfromrefug]

@felixkrautschuk thanks for the details. First i should mention that in your example you should always use the rowHeight. If you dont the collectionview has to assume each cell has its own size and thus has to measure for all items. It gets real slow when you have a lot of items. I know what s happening. I am not 100% sure how RLV works but i think there 2 things:

• collectionview can be improved
• not sure if RLV really supports dynamic cells size and i think it is off by default. which in this case can make a big difference if you dont use rowHeight

Now i published 4.0.72 which should already improve things quite a lot. But i feel i am still behind RLV in your example. I think have a way to make it faster but i need time to implement it.

[felixkrautschuk]

@farfromrefug thanks for your feedback and for publishing the new version. It still takes a while to delete an item on iOS (having a lot items in the list with complex layouts and different cell sizes), but it is already a lot better, so thank you very much!

Yeah, having different cell sizes does not work with RLV anymore since iOS 16+, that's is actually the main reason why we switch from RLV to collectionview (although we need features like header- and footer templates, item selection etc from RLV, that we have to manage manually now with CV).

[farfromrefug]

@felixkrautschuk in this case with the latest version the complexity of your layouts should not make a difference. Only the number of items. Any idea on the number of items in your collection?

[felixkrautschuk]

@farfromrefug "... still takes a while ..." sounds a bit misleading. The time really decreased from about 2500ms to 20ms, so that's totally fine.

The number of elements varies greatly. Everything from 20 to 5000 elements is possible in our collections.

Unfortunately, using the latest version 4.0.72, we now see the same issue with wrong item heights / overlapping items like in RadListView https://github.com/NativeScript/plugins-ui/issues/28.

I am closing this thread and create a new issue for that.

[farfromrefug]

@felixkrautschuk i made a 5.0.0 release which should be even faster. Though it requires testing as a lot of things changed. Let me know if it works for you