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.

Sign up for GitHub

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

Jump to bottom

Query caching for "sticky" scenes (plots, text logs...) #374

Closed
teh-cmc opened this issue Nov 28, 2022 · 5 comments · Fixed by #4853
Closed

Query caching for "sticky" scenes (plots, text logs...) #374

teh-cmc opened this issue Nov 28, 2022 · 5 comments · Fixed by #4853
Assignees
@teh-cmc
Labels
enhancement New feature or request 📉 performance Optimization, memory use, etc ⛃ re_datastore affects the datastore itself 🔍 re_query affects re_query itself user-request This is a pressing issue for one of our users
Milestone
Triage

Comments

@teh-cmc
Copy link
Member

teh-cmc commented Nov 28, 2022

Currently, querying a sticky scene is O(n), and as time goes on it gets more and more laggy.
This is already an issue for plots and text logs today.

Ideally, one would want to cache the results of a query up to now(), and then only query the difference the next frame, and so on and so on.
Problem is: what about out of order data?
@teh-cmc teh-cmc added the enhancement New feature or request label Nov 28, 2022
@teh-cmc teh-cmc added ⛃ re_datastore affects the datastore itself 🔍 re_query affects re_query itself 📉 performance Optimization, memory use, etc labels Feb 28, 2023
@teh-cmc
Copy link
Member Author

teh-cmc commented Mar 6, 2023 •
edited

Also applies to the visible_history feature as a whole, and very much relates to #1331

@teh-cmc
Copy link
Member Author

teh-cmc commented Mar 10, 2023

Screenshot from one of our users hitting this in the wild:
image

@emilk
Copy link
Member

emilk commented Mar 11, 2023

Even without caching I wonder if we can do better than 4µs/get

image

@abey79 abey79 added the user-request This is a pressing issue for one of our users label Sep 12, 2023
@emilk emilk added this to the Triage milestone Nov 1, 2023
@emilk
Copy link
Member

emilk commented Nov 1, 2023

We're finally getting started on this now, though a fix will not likely land before December 2023.

@teh-cmc teh-cmc mentioned this issue Jan 18, 2024
Merged
4 tasks
@teh-cmc
Copy link
Member Author

teh-cmc commented Jan 23, 2024

@teh-cmc teh-cmc closed this as completed Jan 23, 2024
teh-cmc added a commit that referenced this issue Jan 23, 2024
@teh-cmc
Primary caching 18: range invalidation (ENABLED BY DEFAULT 🎊) (#4853)
36446b6 
Implement range invalidation and do a quality pass over all the size
tracking stuff in the cache.

**Range caching is now enabled by default!**

- Fixes #4809 
- Fixes #374

---

Part of the primary caching series of PR (index search, joins,
deserialization):
- #4592
- #4593
- #4659
- #4680 
- #4681
- #4698
- #4711
- #4712
- #4721 
- #4726 
- #4773
- #4784
- #4785
- #4793
- #4800
- #4851
- #4852
- #4853
- #4856
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@teh-cmc teh-cmc

Labels
enhancement New feature or request 📉 performance Optimization, memory use, etc ⛃ re_datastore affects the datastore itself 🔍 re_query affects re_query itself user-request This is a pressing issue for one of our users
Projects
None yet
Milestone
Triage
Development

Successfully merging a pull request may close this issue.

Primary caching 18: range invalidation (ENABLED BY DEFAULT 🎊) rerun-io/rerun
3 participants
@emilk @teh-cmc @abey79