Tag Archives: performance

UIAutomation performance test

I conducted a test that is pretty interesting. As many might know, the more objects on a form, the slower your searches down the Automation tree.
It was measured that search on a form containing an Infragistics grid with 250 rows and 6 columns (i.e., 1500 cells) may take up to fifteen minutes. It depends on many conditions, for example, if a host is relatively ‘fresh’, it takes 383 seconds, i.e. just more than six minutes.
To demystify the topic, I ran the following test:
a simple .NET form with a DataGrid:

The ‘button1’ button creates two columns, the ‘button2’ button adds ten rows per click.

This is the test script:

Get-UIAWindow -n Form1 | Get-UIAButton -n button1 | Invoke-UIAButtonClick;
for ($i = 0; $i -lt 20; $i++) {
 Get-UIAWindow -n Form1 | Get-UIAButton -n button2 | Invoke-UIAButtonClick;
 Write-Host "$(($i + 1) * 10) rows";
 "$(($i + 1) * 10) rows" >> "C:\1\grid_report.txt";
 Measure-Command -Expr {
 Get-UIAWindow -n Form1 | Get-UIATable | Get-UIAControlDescendants | %{Write-Host "$($_.Current.Name)`t$($_.Current.AutomationId)`t$($_.Current.ClassName)`t$($_.Current.ControlType.ProgrammaticName)`t$(($_.GetCurrentPattern([System.Windows.Automation.ValuePattern]::Pattern) -as [System.Windows.Automation.ValuePattern]).Current.Value)";}
 } >> "C:\1\grid_report.txt";

The script initializes the form by pressing the ‘button1’ button and performs twenty cycles. Each cycle, the script increases the number of rows in the grid and measures the search time.
In other words, our test measures the speed of search below the grid for the increasing number of rows with the increment equaling to 10.
The results are in the table (the test was performed on a Intel965 box with Windows 8 RP, 6GB RAM and the lowest Crucial M4 SSD):

Surprisingly, even though time the search took is increasing with the increase of the rows number, the objects per second time gradually decreases.
Here are two charts to make it more perceptible:

Both charts tell us two things:

  • the objects per second time is growing not to fast as the number of objects in the grid does, it grows slower
  • somewhere after 150 objects, time of the test begins increasing faster and faster.

The latter fact will be the reason for other tests in the near future (I’ll be informing the community about results).

Finally, the bare speed is not so valuable without other measurements. How much memory has been consumed? After the test, the Task Manager displays that:

The amount of memory is not so shocking if we compare it with the amount SharpDevelop consumes. One instance of SharpDevelop is the instance which the test app has been run from. The second instance did no more than was open with the UIAutomation solution loaded.

The normal amount of memory PowerShell consumes on this host is between 32 and 34 Megabytes, varying from run to run:

The test app, the script and the results are in the Box at the right.

A word of appreciation: Windows 8 accessibility performance improvements

Compared to runs on a Windows 7 x64 box as well as on a Windows 2008 SP2 x64 box, the same script from the post gave the great difference in the work with the FindAll call:

to get the AutomationElement corresponding to the Workstation service (at the bottom of the grid) through the FindFirst call takes the same time as to get this element by using FindAll with iteration through the collection.

If you ran the script on a Window 7 or Windows 2008 box, you probably noticed that the latter way is slower than the former as much  as several times.

On the opposite, on a Windows 8 CP x64 box and on a Windwos Server 8 Beta box, both times are almost equal.

Viva, Microsoft UI Automation team! You embedded something (I think it’s caching always ON) that greatly improved the performance of control collections.

%d bloggers like this: