Performance improvement for AXPosition<>::AsTreePosition
While investigating opportunities where AXRange<>::{begin|end}() can be improved, I found that AsTreePosition was one of the higher cost methods. This is because it's called many times in order to create an AXRange<>::Iterator. Both AXRange<>::AsForwardRange and the Iterator constructor via AXPosition<>::AsLeafTextPosition call AsTreePosition. The reason it's expensive is because of AXPosition<>::MaxTextOffset. For the scenario I was measuring, this CL reduced the overall amount of time spent in AXRange::begin by ~30-35%, and the overall amount of time spent in AXPosition<>::AsTreePosition by ~50%. I crafted a document where there are many inline nodes that form sentences with various levels of nesting, and used Narrator with UIA enabled to navigate 5 sentences. I used "UI for ETW" to capture perf traces, and WPA to view the data. Before : * Weight for callees of AXRange<>::begin : 7889 * Weight for callees of AXPosition<>::AsTreePosition : 20418 After : * Weight for callees of AXRange<>::begin : 5246 * Weight for callees of AXPosition<>::AsTreePosition : 10298 Bug: 928948 Change-Id: I24be1be302b9e22bc85412f091b5f464274f1dfb Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1824064 Commit-Queue: Nektarios Paisios <nektar@chromium.org> Reviewed-by:Kurt Catti-Schmidt <kschmi@microsoft.com> Reviewed-by:
Nektarios Paisios <nektar@chromium.org> Cr-Commit-Position: refs/heads/master@{#702075}
Showing
Please register or sign in to comment