Fix search container filtering too much#5578
Merged
peppy merged 2 commits intoppy:masterfrom Dec 12, 2022
Merged
Conversation
As it turns out, 99915f9 introduced a performance regression in `SearchContainer`. Due to borrowing from ppy#5154 too much, the search logic was changed in order to hook into `InvalidateLayout()` 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 in `SearchContainer` considers lifetime explicitly. - `FlowContainer.childLayout` becoming invalid: The invalidation flags there are `RequiredParentSizeToFit | Presence`. Neither should be relevant for filtering, given the direction taken with `IConditionalFilterable`. - `Direction` and `Spacing`: 100% irrelevant.
Member
|
Change seems good, and may help more in other cases, but doesn't seem to do much here (as expected, the JIT is still the killer): Before: 4,444 calls to JIT: 104ms After: 2,229 calls to JIT: 104ms |
peppy
approved these changes
Dec 12, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 inSearchContainerconsiders lifetime explicitly.FlowContainer.childLayoutbecoming invalid: The invalidation flags there areRequiredParentSizeToFit | Presence. Neither should be relevant for filtering, given the direction taken withIConditionalFilterable.DirectionandSpacing: 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
childLayoutinvalidations - so I before I dig in any further I want to see if this at least restores baseline performance.