Look for the review where it lives, not across the whole desktop - #102
Merged
Conversation
Review discovery searched TreeScope.Descendants from the desktop root, which walks every window of every running application - twice whenever the review was absent, because it tried the identifier and then the title. It runs on every 50 ms poll of several waits. Measured before changing anything, by timing the lookups directly rather than inferring from total runtime: 7.9s and 7.8s of a 22.5s suite run on a desktop holding ten windows, against 4.1s and 4.2s on one holding five. The cost tracked what else the machine had on screen, which is not something a test result should depend on. It was noticing that runs went faster with EC alone on a desktop that prompted the measurement. Where the review actually lives was measured too, after a first attempt scoped to the desktop's immediate children found nothing and failed six runs out of six: an owned dialog is not a top-level window. Probing all four scopes while a review was open gives root/children=no, root/descendants=yes, main/children=yes, main/descendants=yes. It sits among the main window's own children, so that is where it is looked for, with identifier or title in one condition instead of two searches. Scoping to the main window also makes the process filter redundant. Automation errors are not caught here. Returning null for one would report the review as absent when the truth is that nothing could be read, and the waits that call this already retry and keep the error - the same erasure this driver has had to fix twice before. Full suite on the same cluttered desktop: 17.3s and 17.6s, against 22.7s and 22.3s before. On a fresh desktop: 17.8s and 17.7s - the gap that tracked desktop clutter is gone, and it is faster than the old best case. Six consecutive runs pass after the corrections, and the unit suite is unchanged at 756. Other descendant searches are left alone. EC is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
amrali-eg
force-pushed
the
perf/review-window-lookup
branch
from
September 10, 2026 08:09
f59434b to
0b0bc77
Compare
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.
One commit, one method. Independent of #101 - both touch
EcGuiDriver.csindifferent places, so whichever merges second may want a rebase. No production
code changes.
The cost
FindReviewWindowsearchedTreeScope.Descendantsfrom the desktop root, walkingevery window of every running application - twice whenever the review was absent,
since it tried the identifier and then the title. It runs on every 50 ms poll of
several waits.
Measured directly, by timing the lookups rather than inferring from total runtime:
Same number of lookups either way. About 35% of a run was spent walking other
applications' window trees, and the price tracked what else the machine had on
screen - not something a test result should depend on. The measurement was
prompted by noticing that runs went faster with EC alone on a desktop.
Where the review actually lives
Measured, not assumed - after a first attempt scoped to the desktop's immediate
children found nothing and failed six runs out of six. An owned dialog is not a
top-level window. Probing all four scopes with a review open:
It sits among the main window's own children, so that is where it is looked for,
with identifier or title in one condition instead of two searches. Scoping to the
main window makes the process filter redundant.
Automation errors are deliberately not caught here: returning null for one
would report the review as absent when the truth is that nothing could be read,
and the waits that call this already retry and keep the error. That erasure has
had to be fixed twice before in this driver.
Result
The gap that tracked desktop clutter is gone, and it beats the old best case -
roughly 24% off the suite. Six consecutive full runs pass, four more standalone on
master after the split, and the unit suite is unchanged at 756.
Other descendant searches are left alone.
🤖 Generated with Claude Code