Fix search container filtering too much #5578
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As it turns out, 99915f9 introduced a performance regression in
SearchContainer
. Due to borrowing from #5154 too much (see relevant discord conversation), the search logic was changed in order to hook intoInvalidateLayout()
to perform search, rather than just do it when a new internal child was added, as was the case previously.For the sake of completeness, let's review the possible causes for
InvalidateLayout()
firing with respect to filtering:AddInternal()
: Valid, as the new child needs to be examined against the current filter, and preserved by reverting to the old code.RemoveInternal()
: Mostly irrelevant, as long as the presence of the removed drawable in the container doesn't impact the filter state of any of its siblings. Let's not support that case for now.ClearInternal()
: Totally irrelevant, as anything that could be filtered is now gone.SetLayoutPosition()
: Hopefully irrelevant.UpdateChildrenLife()
: Not relevant. Nothing inSearchContainer
considers lifetime explicitly.FlowContainer.childLayout
becoming invalid: The invalidation flags there areRequiredParentSizeToFit | Presence
. Neither should be relevant for filtering, given the direction taken withIConditionalFilterable
.Direction
andSpacing
: 100% irrelevant.@peppy Would appreciate it if you ran this through your perf wringer and see if it helps any with the blocking load issue pointed out on discord. This does nothing for the JIT overhead pointed out therein, but this pull should cull some hundreds of extraneous filters that could be triggered on some (but not all, from my testing) game-side settings sidebar loads, and those extra calls mostly stemmed from the
childLayout
invalidations - so I before I dig in any further I want to see if this at least restores baseline performance.