Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve setSelected performance when large concept lists are in use #645

Open
stefandesu opened this issue Nov 16, 2021 · 1 comment
Open
Labels
cleanup code cleanup, refactoring, testing... low priority maybe later
Milestone

Comments

@stefandesu
Copy link
Member

Selecting a new concept gets slower the larger the concept lists are. It's pretty much unnoticeable with "normal"-sized lists, but as soon as you get to a few thousand concepts, there's a significant delay between clicking a concept and it being selected (testing with all of ~8000 Thema concepts in a single list, I'd say the delay is between .5 and 1 second).

@stefandesu stefandesu added cleanup code cleanup, refactoring, testing... low priority maybe later labels Nov 16, 2021
@stefandesu stefandesu added this to the 1.7.0 milestone Nov 16, 2021
@stefandesu
Copy link
Member Author

One idea I had was this:

  1. Perform ALL modifications on items via modifyItem (this should in theory already be the case).
  2. Add a system where components can ask to be notified only when a certain concept changes (this could be used in other parts of Cocoda as well).
  3. Notify ItemList only about changes for concepts that are currently in view, and only update that part of the list. Other parts are irrelevant in that moment.

Not sure if this could work, but it's worth a try.

@nichtich nichtich modified the milestones: 1.10.0, 1.11.0 Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup code cleanup, refactoring, testing... low priority maybe later
Projects
None yet
Development

No branches or pull requests

2 participants