Finding an element with an XPath locator is very slow

[PiotrNestor]

@aristotelos

FlaUI.WebDriver Version: v0.3.1

We have a complex legacy Desktop application that exposes FrameworkType Win32 automation interface.

An example XPath like: //Tab[@name='customers']//Text[contains(@name,'Drag and drop field here')]
can take up to 45 seconds to locate the related element.
Note that even a full Xpath for the above element example takes 10 seconds to locate the element.

What can be done to speed up this mechanism?
Any suggestions for a locator strategy that could improve the situation?

[PiotrNestor]

Some additional findings when using FLaUInspect (UIA3 mode) with the above app:

• it's possible to find, build and expand the above element properties in the elements structure within 1-2 seconds
• selecting the element in question in the FlaUInspect element structure, highlights the element in the application within 1-2 seconds. Also, the element's bounding rectangle is recalculated instantly when moving and resizing the application.

So, obviously it's possible to manipulate the app elements very quickly via the exposed automation. But using XPath locators is very slow ...

[aristotelos]

It may be that not the X-Path is slow, but the resolving of the top level window to which the X-Path is resolved relatively. I myself have experienced that the GetAllTopLevelWindows() is very slow in FlaUI / Windows automation itself. See also FlaUI/FlaUI#616, FlaUI/FlaUI#596. Could that be the case?

If it is the X-Path, it may be sped up by avoiding the use of // (recursive search) and using / (children search) instead. In general, I would recommend the use of automation IDs and not X-Path.

[PiotrNestor]

@aristotelos
This is unclear or confusing :(

I was under the impression that all XPath like '//...' are relative to the present driver window ...

In our implementation, the code is performing driver.SwitchTo().Window(handle)
Example

...
    var handles = driver.WindowHandles;
    foreach (var handle in handles)
    {
        driver.SwitchTo().Window(handle);

        // Check if an UI element for the window is visible
        // if so ... return
    }

Obviously we try to use 'AutomationId' is available. Unfortunately these are not available in many cases.
XPath with single, initial '//' are mostly very fast
Only more complex XPath with multiple '//' might be very slow where the application's window element structure is deep