-
Notifications
You must be signed in to change notification settings - Fork 334
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
Speed up query usage in heuristics by splitting DataQuery into separate query and update_properties passes #4563
Conversation
3f0cd4a
to
f3e06ae
Compare
80d3841
to
5a0d21e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the code needs to clear up better what's fast vs normal. Looks & feels very hacky right now. Let's maybe talk it through a bit
@@ -117,7 +117,7 @@ pub struct SelectionState { | |||
impl SelectionState { | |||
/// Called at the start of each frame | |||
pub fn on_frame_start(&mut self, item_retain_condition: impl Fn(&Item) -> bool) { | |||
re_tracing::profile_function!(); | |||
re_tracing::profile_scope!("SelectionState::on_frame_start"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't that esactly what the profile_function macro prints, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not quite -- it seems like puffin doesn't track the struct name and so I was seeing two calls to on_frame_start
coming from different call-sites resulting in some unexpected aggregation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that with latest puffin? afaik what scopes are merged when improved a bit, but might have been mostly about traits
0329e12
to
18571c5
Compare
18571c5
to
b822d31
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so much better, flow is totally clear now! The only wrinkle now is the thing you already put in the comments of having the same query results object with and without filled out properties
// to do this or else the auto_properties aren't right since they get populated | ||
// in on_frame_start, but on_frame_start also needs the queries. | ||
let updated_query_results = { | ||
{ | ||
re_tracing::profile_scope!("updated_query_results"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: more like "update_overrides"
now
What
After adding some scopes, found some more wins on query processing. This is a mixture of some optimized short-circuit early-outs, and doing the PropertyOverride logic on a second-pass in order to avoid any overhead related to creating the EntityProperty structures and override entity-paths.
This has the added benefit of also removing the second query and replacing it with a much easier-to-follow override processor.
Before:
After:
Checklist
main
build: app.rerun.ionightly
build: app.rerun.io