Using Caching with AutomationElements does not give me a speedup - intended or wrong usage?

Question

I am trying to increase the speed of some UI Automation operations. I stumbled across the (not so well) documented caching possibility.

From what I have understood, the whole operation (if you have a large GUI-tree) is so slow, because for every single function call there has to be a process-change (kind of like going to kernel-mode, I suppose, speed-wise?!). So.. in comes caching.

Simply tell the function to cache an element and its children, and then work on it lightning-fast. (From what I understand, you only have one context-change, and assemble all the data you need in one go.)

Good idea, but.. it is just as slow for me as the uncached variation. I wrote some simple testcode, and could not see an improvement.

AutomationElement ae; // element whose siblings are to be examined, thre are quite a few siblings
AutomationElement sibling;

#region non-cached
watch.Start();
for (int i = 0; i < 10; ++i)
{
    sibling = TreeWalker.RawViewWalker.GetFirstChild(TreeWalker.RawViewWalker.GetParent(ae));
    while (sibling != null)
    {
        sibling = TreeWalker.RawViewWalker.GetNextSibling(sibling);
    }
}
watch.Stop();
System.Diagnostics.Debug.WriteLine("Execution time without cache: " + watch.ElapsedMilliseconds + " ms.");
#endregion

#region cached
watch.Reset();
watch.Start();

CacheRequest cacheRequest = new CacheRequest();
cacheRequest.TreeScope = TreeScope.Children | TreeScope.Element; // for testing I chose a minimal set
AutomationElement parent;

for (int j = 0; j < 10; ++j)
{
    using (cacheRequest.Activate())
    {
        parent = TreeWalker.RawViewWalker.GetParent(ae, cacheRequest);
    }
    int cnt = parent.CachedChildren.Count;
    for (int i = 0; i < cnt; ++i)
    {
        sibling = parent.CachedChildren[i];
    }
}
watch.Stop();
System.Diagnostics.Debug.WriteLine("Execution time parentcache: " + watch.ElapsedMilliseconds + " ms.");
#endregion

The setup is: you get an element and want to check on all its (many) siblings. Both implementations, without and with cache, are given.

The output (debug mode): Execution time without cache: 1130 ms. Execution time parentcache: 1271 ms.

Why is this not working? How to improve?

Thanks for any ideas!!!

Actually, I found some interesting pointers here http://social.msdn.microsoft.com/Forums/en-US/windowsaccessibilityandautomation/thread/90e05e0c-8afd-478e-8683-af421d711117 - so it looks like I will have to go the COM way - as soon as I find the time (which right now is not the case). I will tell you if it gives a noticeable improvement. — Andreas Reiff, Jul 04 '11 at 12:21
It is obvious that there is no difference is speed. In both cases the Automation framework must iterate through all children of the element which obviously take the same time. But you would notice a difference if your code would iterate through the same children a SECOND time. (once getting the children again non-cached and once getting them from the cache) So at the end: Your code is designed wrongly for a benchmark test. — Elmue, Nov 17 '16 at 13:02
ATTENTION: I experimented more with the cache and the result is that using the cache makes navigation to children SIGNIFICANTLY slower than not using the cache! — Elmue, Nov 17 '16 at 14:36

score 2 · Answer 1 · answered May 17 '11 at 14:47

I would not expect the two loops to differ much in their running time, since in both cases the parent's children must be fully walked (in the first explicitly, and in the second to populate the cache.) I do think, though, that the time required for looping through the parent.CachedChildren array is much lower than your initial walk code. At that point, the elements should be cached, and you can use them without re-walking the tree.

The general point is that you can't get performance for free, since you need to invest the time to actually populate the cache before it becomes useful.

I want performance for free. :) Seriously.. I thought the performance-gain would not come for multiple access to the items (which I don't want) but from skipping the context-changes? — Andreas Reiff, May 17 '11 at 15:08

score 0 · Accepted Answer · answered Jun 26 '12 at 09:45

Actually, recently I found the time to check it again, and also against different UI elements. For caching to be faster, one first has to specify all (and only) the needed elements. There is a real performance difference if you e. g. look at a ComboBox with 100 elements inside or something similar, like a very complicated GUI with a lot of elements on the same hierarchy level - and you actually need the data from all of them. So.. caching is not a solution for everything but rather a performance-optimization-tool that has to be applied with.. knowledge about the situation, the requirements and the internal working. BTW, talking about performance, I found out that each .current access to a UI element take very roughly 20ms, so for complex operations this really can reach a significant time.

Using Caching with AutomationElements does not give me a speedup - intended or wrong usage?

2 Answers2