Conversation
This reverts commit 0534aa0.
|
|
|
It... has not? It seems to be the exact same as |
|
Okay, according to others, the memory usage is not supposed to change all that much. What should improve is ingestion speed. |
|
I've just tried it and I can already tell you right now that your branch is a good order of magnitude faster :D Nice! |
|
In terms of testing, as I was working on this I would manually add logs to the places with code changes just to make sure that those code paths are actually being hit and are still doing the right thing. The logs would print both the old and new values, so I could compare them. I think there should be no observable changes between this branch and |
teh-cmc
left a comment
There was a problem hiding this comment.
Works great.
Now we have to make our semantics consistent across the board.
| query_caches.on_events(store_events); | ||
|
|
||
| tree.on_store_deletions(store_events); | ||
| // Tree deletions depend on data store, so data store must have been notified of deletions already. |
There was a problem hiding this comment.
I'm confused by this comment -- the data store is the thing that emitted the changelog in the first place, how could it not know about what's in it?
There was a problem hiding this comment.
Yes, the problem here is that the store events are not actually being used by the tree anymore, so there's no direct dependency between them, which is inconsistent with the rest of the function, where everything else uses the store events. Just wanted to make that as clear as possible
There was a problem hiding this comment.
I guess I can just add the param back and then not use it
| /// Returns `false` if this entity has no children and no data. | ||
| pub fn is_empty(&self, chunk_store: &ChunkStore) -> bool { | ||
| self.children.is_empty() | ||
| && !chunk_store.entity_has_any_component_on_any_timeline(&self.path) |
There was a problem hiding this comment.
Okay I'm starting to see where the ambiguities stem from.
What do you really want to know here: whether the entity has some component associated with it (which, once true, will always be true -- no matter of what the GC ends up removing), or whether the entity has some events available in the store (which can be true at some point but then false at a later time because GC)?
This method should make it clear which one of these is at play here.
We need to make that clear all over the place in all these store APIs and their docs, in fact.
There was a problem hiding this comment.
If I look at it from the perspective of the time panel, it should not display any entities which do not actually have any visible data (either static or temporal). The way I understand it, that's how it worked previously:
The component was removed from that entity in the entity tree if the histogram was empty, which means the time panel would no longer show that component, and if it had no components and no children left, it would be removed completely.
I'll properly name all the APIs with data or component depending on what they're looking for, and make the distinction clear in their docs.
There was a problem hiding this comment.
Ha-ha! Now I see why you need those.
There was a problem hiding this comment.
Yeah, it's just one specific place where we give the user some more information about what they're doing wrong
Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>
Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>
Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>
Co-authored-by: Clement Rey <cr.rey.clement@gmail.com>
Regression introduced in #6934 and caught by `check_static_components_ui` Before:  After: 

What
This PR removes all usage of the recursive time histograms tracked in
EntityTree. The entity tree now only represents the... tree of entities, and no other information about them. All required information is queried from the database on demand.TimeHistogram#6065Checklist
mainbuild: rerun.io/viewernightlybuild: rerun.io/viewerCHANGELOG.mdand the migration guideTo run all checks from
main, comment on the PR with@rerun-bot full-check.