Skip to content

perf(query-core): useQueries have quadratic performance in relation to the number of queries(#8604) #8686

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

zktm9903
Copy link

Task

issue
comment

Modification

This change optimizes the time complexity of the #onUpdate function in queriesObserver from O(n) to O(1).

  #onUpdate(observer: QueryObserver, result: QueryObserverResult): void {
    const index = this.#observerMap.get(observer)
    if (index !== undefined) {
      this.#result = replaceAt(this.#result, index, result)
      this.#notify()
    }
  }

…o the number of queries(TanStack#8604)
Copy link
Collaborator

@TkDodo TkDodo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not a fan of storing the observers in both a Map and an Array, and the whole thing becomes more complex.

The only reason we have an Array is because users pass in Array<QueryObserverOptions>, and we need to keep that order. Maybe storing this as a Map<index, QueryObserver> only would work?

TkDodo and others added 2 commits February 28, 2025 11:55
@zktm9903
Copy link
Author

I’m not a fan of storing the observers in both a Map and an Array, and the whole thing becomes more complex.

The only reason we have an Array is because users pass in Array<QueryObserverOptions>, and we need to keep that order. Maybe storing this as a Map<index, QueryObserver> only would work?

You're absolutely right. Fundamentally, we need to preserve the order, so using an array is necessary. Alternatively, it’s possible to use a Map and include the order in the values (rather than the keys), but based on my attempt, it significantly increased code complexity.
I believe this PR improves performance while keeping the code complexity to a minimum, though I completely agree with your concerns regarding complexity as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants