[Feature Request]: Use Set and Map instead of arrays where applicable

[kommunarr]

Guidelines

• I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
• I have searched the documentation for information that matches the description of the feature request I want to file, without success.
• This issue contains only one feature request.

Problem Description

We currently use arrays in many places where sets and maps would be far more performant. This is notable particularly for oft-repeated operations and collections of reasonable size (>50-100+).

Proposed Solution

Replace arrays with the better-suited data structures of Set and Map for larger collections where searching is commonly done. This is overwhelmingly present in store/modules, so that can be considered the scope for this story, although I'd recommend checking any other one-off instances just in case.

Alternatives Considered

None

Issue Labels

improvement to existing feature

Additional Information

Functionally dependent on #4428, since Maps and Sets are only reactive in Vue 3.

[absidue]

I really don't think we need an issue open for something like this, considering that literally the only reason we haven't done it yet is because it's literally not possible at the moment and because it's so vague that'll we'll never be able to actually close it, because there will always be something that can be more optimised.

[kommunarr]

I can try to attach it to particular action items if desired, I'd just need to take a deeper look. Main idea is that the PR addressing it would inspect it in depth and resolve it. I can also limit scope specifically to store/modules, I'm just not completely sure if there are any other one-off areas we'd need to check.

[absidue]

This doesn't need investigation or action items, we especially don't need an issue open that is worded in way that makes it sound like we chose to use inefficient data types when that couldn't be further from the truth.

[kommunarr]

This doesn't need investigation or action items, we especially don't need an issue open that is worded in way that makes it sound like we chose to use inefficient data types when that couldn't be further from the truth.

I'm not sure if the wording of the issue relates to whether the issue needs any investigation, but I will close the issue if it is causing an unexpected argument. I didn't expect this to be controversial.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I think this suits https://github.com/FreeTubeApp/FreeTube/projects/10 more than our issue board

[absidue]

Part of my problem with this issue is that you are misdiagnosing the cause of the performance problems. Vue's store is many times slower in dev mode than in production builds, Vue 2's reactivity is slow, especially noticeable in FreeTube because of the unreasonably large amount of items that we try to display on screen at the same time. I don't blame you for not knowing that, all of your PRs are UI stuff. Our core problem isn't bad data structures, it's bad UI.

[kommunarr]

I didn't think it was the root cause of problems, but I do think it's a minor improvement that could be made for things like large quantities of videos / playlist videos where we're doing search, targeted insertion, and targeted removal operations on them. I apologize that I misstated the importance, if I said something relating to the salience or degree in the issue description. That's my bad.

[absidue]

Maps and Sets won't help much with the playlists, unless we finally get rid of the ability to add the same video to a playlist multiple times. They also don't address the fact that the reason those are slow in FreeTube is because we make those structures reactive, so there is added overhead to every single property access both during reading and writing.