Forum Discussion

TimoF's avatar
TimoF
Occasional Contributor
9 years ago

Performance Issues with objects using "Extended Find" in TC 11.20

I upgraded my TC installation from Version 10.x to TC Version 11.20.

 

With the new TC 11.20 installation I have to face performance problems with my tests which are using  objects mapped via "Extended Find". Test runs consume approximately 30% to 40% more time than before.

 

I tried to add additional mapping levels in my NameMapping tree but it was not sufficient to speed-up the test execution.

A complete mapping of the affected objects is no option for me because the internal structure of  the AUT is changing a lot.

Therefore tests stability across different versions of AUT is of primary importance for me.

 

My questions are:

  • Am I the only one facing this performance problem?
  • Is there a solution or workaround?

Regards,

Timo

  • TimoF's avatar
    TimoF
    9 years ago

    I got a solution from the smartbear support. With the new TC 11.20 version the namemapping find algorithm was reworked.

    In some cases this new algorithm is slower than the old algorithm from TC 10.

     

    TestComplete can be launched with the "/UseOldFindAlgorithm" command-line argument. With this argument TC11.20 uses the old TC10 find algorithm.

     

    You can do this in two ways:

    1. Press the "Win" + "R" keyboard keys and execute the following command:
    "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm

    2. Navigate to the Properties of the TestComplete shortcut and add the /UseOldFindAlgorithm command-line argument to the Target field:
    "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm

     

    This solution also works for TestExecute. I just added the "UseOldFindAlgorithm" parameter to the TestExecute command-line calls in my batch-files.

     

    Regards,

    Timo

  • TimoF's avatar
    TimoF
    Occasional Contributor
    9 years ago

    I got a solution from the smartbear support. With the new TC 11.20 version the namemapping find algorithm was reworked.

    In some cases this new algorithm is slower than the old algorithm from TC 10.

     

    TestComplete can be launched with the "/UseOldFindAlgorithm" command-line argument. With this argument TC11.20 uses the old TC10 find algorithm.

     

    You can do this in two ways:

    1. Press the "Win" + "R" keyboard keys and execute the following command:
    "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm

    2. Navigate to the Properties of the TestComplete shortcut and add the /UseOldFindAlgorithm command-line argument to the Target field:
    "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm

     

    This solution also works for TestExecute. I just added the "UseOldFindAlgorithm" parameter to the TestExecute command-line calls in my batch-files.

     

    Regards,

    Timo

  • djadhav's avatar
    djadhav
    Regular Contributor
    9 years ago

    This is just to zoom into the actual problem. Have you noticed anything in particular that makes you believe it is the 'objects mapped via Extended Find' that is causing the performance issue? Can you describe exctly what delays the test performance?

  • TimoF's avatar
    TimoF
    Occasional Contributor
    9 years ago

    Hi djadhav,

     

    thank you for your reply. The AUT uses DevExpress controls where it is difficult (perhaps only for me) to detect the loading state of the control (e.g. switching to another page in a DevExpress grid control).

     

    My approach to detect the ready state of the control:

            do {
          // JobFolder still loading
          NameMapping.Sys.Refresh();
          NameMapping.Sys.RefreshMappingInfo();
          IterCount++;         
        } while (LoadingTN.WaitProperty("VisibleOnScreen", true, 1000) == true && IterCount < MAXITER)

     

    LoadingTN is the control which indicates the loading state. I'm using this kind of code block over my whole projects. Please correct me if I'm doing it wrong or if there is a better approach.

     

    My understanding is that this code block waits maximal one second and jumps to the next iteration until the LoadingTN control is no longer visible.

     

    I execute my tests on a virtual machine which is not as fast as my local maschine. Since updating to TC 11.20 I have "Searching for a mapped object took too much time" warnings in the mentioned code blocks in my testlog which I did not have before.

     

    When I execute the tests on my local maschine I also observe longer wait times in the mentioned code block. I assume it is because of the LoadingTN control is mapped via Extended Find. The TestComplete indicator displays the searching of the LoadingTN control (takes several seconds -> unexpected behaviour) and the WaitProperty() call (takes 1 second -> expected behaviour).

     

    Thank you in advance.

     

    Regards,

    Timo

  • TimoF's avatar
    TimoF
    Occasional Contributor
    9 years ago

    Nobody facing the same performance issues?

     

    I found another code block which consumes additional time with TC 11.20:

     

    if (Global_LoginPage.WaitNamedChild("P_LoginError",3000).Exists)
{
   // do something
}

    With TC 10.x this code block had a maximal delay of 3s. With TC 11.20 i face delays bigger than 10s.

     

     

    I really appreciate your help.

     

    Regards,

    Timo