query
query copied to clipboard
perf(queryClient): use `queryCache.get` instead of `find({ queryKey })`
Methods that access a query by its queryKey can bypass find to avoid performance issues in large caches.
Fixes #6783
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| query | ⬜️ Ignored (Inspect) | Visit Preview | Feb 18, 2024 8:40am |
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Latest deployment of this branch, based on commit abc32bc18cbf42f59ef55ed67675dee8fc81ed23:
| Sandbox | Source |
|---|---|
| @tanstack/query-example-angular-basic | Configuration |
| @tanstack/query-example-react-basic-typescript | Configuration |
| @tanstack/query-example-solid-basic-typescript | Configuration |
| @tanstack/query-example-svelte-basic | Configuration |
| @tanstack/query-example-vue-basic | Configuration |
☁️ Nx Cloud Report
CI is running/has finished running commands for commit abc32bc18cbf42f59ef55ed67675dee8fc81ed23. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.
📂 See all runs for this CI Pipeline Execution
✅ Successfully ran 1 target
Sent with 💌 from NxCloud.
sadly, the performance tests are already flaky:
- https://cloud.nx.app/runs/puVC4nNo9c?utm_source=pull-request&utm_medium=comment
❯ |@tanstack/query-core| src/tests/queryClient.test.tsx (91 tests | 2 failed) 5414ms
❯ src/tests/queryClient.test.tsx > queryClient > setQueryData > should set 10k data in less than 500ms
→ expected 927.7827839851379 to be less than 500
❯ src/tests/queryClient.test.tsx > queryClient > getQueryState > should get 10k queries in less than 500ms
→ expected 603.6593210101128 to be less than 500
is there anything we can do here please ?
I could try increasing the threshold to 2000ms and maybe go up to 20k rows. - On my machine, 10k rows without the fix took far longer (30s IIRC) so it should be possible to find a decent threshold.
The purpose of the test is primarily to check the complexity.
On second thought, I might try going down to 5k in 500ms so as to not unnecessarily slow down the pipeline.
I'll do that now.
@TkDodo I'm attempting a fix in #6937