CodeJock Toolkit: FindSingle perfomance

Class library usage, coding and language questions.
i.vasilyev
Posts: 30
Joined: Fri Sep 09, 2016 10:14 am

CodeJock Toolkit: FindSingle perfomance

Post by i.vasilyev » Fri Jun 02, 2017 4:30 pm

Hello.

Env:
Ranorex 7.0
VS(ranorex.core is in references)
AUT is a desktop app

My application is using CodeJock Toolkit and FindSingle takes too much time for find element(sometimes about 40sec). The same time is needed for Spy for find element
Is it possible to improve the performance? Any suggestions may be helpful.

Example of FindSingle:

Code: Select all

Host.Local.FindSingle<T>(locator, waitParams.FindElementTimeOut);

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 3930
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: CodeJock Toolkit: FindSingle perfomance

Post by odklizec » Fri Jun 02, 2017 7:45 pm

Hi,

Please post the xpath for searched element and a Ranorex snapshot (not screenshot) of this element. It's pretty hard (impossible) to suggest something reliable without these two things. My guess is that the searched xpath is not specific enough or too general, so Ranorex needs to search the whole GUI to find it. And this may take some time.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: CodeJock Toolkit: FindSingle perfomance

Post by Stub » Mon Jun 05, 2017 8:23 am

We use the CodeJock Toolkit too, and while it does take a while to find elements on our Ribbon UI, it's nowhere near 40s! I figured it was because the Ribbon element has an awful lot of items as children, even if only some are shown at any one time.

I found that if I saved the control in a property of a test module it was much faster than repeatedly trying to find the control over and over. I had to cache the control in the test module CTOR rather than find it repeatedly in the Run method.

i.vasilyev
Posts: 30
Joined: Fri Sep 09, 2016 10:14 am

Re: CodeJock Toolkit: FindSingle perfomance

Post by i.vasilyev » Mon Jun 05, 2017 2:50 pm

Stub wrote:We use the CodeJock Toolkit too, and while it does take a while to find elements on our Ribbon UI, it's nowhere near 40s! I figured it was because the Ribbon element has an awful lot of items as children, even if only some are shown at any one time.

I found that if I saved the control in a property of a test module it was much faster than repeatedly trying to find the control over and over. I had to cache the control in the test module CTOR rather than find it repeatedly in the Run method.
Hello, thanks for your suggestion.
Can you provide a small example of that implementation?

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: CodeJock Toolkit: FindSingle perfomance

Post by Stub » Tue Jun 06, 2017 8:34 am

Something along these lines:

Code: Select all

public class Undo : ITestModule
{
    private Button QATUndo { get; set; }

        public Undo()
        {
            QATUndo = Ribbon.QuickAccessToolbar.Undo;
        }

        void ITestModule.Run()
        {
            QATUndo.Click(Location.CenterLeft);
        }
}
That lets me click the Undo button on our quick access toolbar much more rapidly than if I had to grab it each time in the Run method. No idea if there's a better way yet, but that's working for me. It's crucial you save it in the CTOR. It then persists when used later.

i.vasilyev
Posts: 30
Joined: Fri Sep 09, 2016 10:14 am

Re: CodeJock Toolkit: FindSingle perfomance

Post by i.vasilyev » Tue Jun 06, 2017 7:39 pm

I investigated the problem and I have following results:
My toolbar contains about 300 buttons. Sorry, I can't attach snapshot but tree is following:

Code: Select all

form
       toolbar
                  button1
                  button2
                  ....
                  tabpagelist
                                  tabpage1
                                  tabpage2
                                  ...
                                  tabpageN
                  buttonN
Steps:
1. Application opens
2. Default tab(Tab 1) is selected
3. Click on "Tab1" and click on button "ButtonOnTab1"
4. Click on "Tab3" and click on button "ButtonOnTab3"
5. Click on "Tab3" and click on button "ButtonOnTab3"
6. Click on "Tab1" and click on button "ButtonOnTab1"
7. Click on "Tab1" and click on button "ButtonOnTab1"

Result:
RibbonNavigationsSteps.NavigateToTabAndClickOnButton(Tab1, ButtonOnTab1) (7.4s)
RibbonNavigationsSteps.NavigateToTabAndClickOnButton(Tab3, ButtonOnTab3) (17.7s)
RibbonNavigationsSteps.NavigateToTabAndClickOnButton(Tab3, ButtonOnTab3) (31.1s)
RibbonNavigationsSteps.NavigateToTabAndClickOnButton(Tab1, ButtonOnTab1) (42.1s)
RibbonNavigationsSteps.NavigateToTabAndClickOnButton(Tab1, ButtonOnTab1) (52.6s)

How I'm selecting tab and clicking on button

Code: Select all

FindSingle<TabPage>(/form/toolbar/tabpagelist/tabpage[@title='Tab 1']).Click();
FindSingle<Button>(/form/toolbar/Button[@title='ButtonOnTab1' and @visible='true']).Click();
Also I tried to save toolbar element in CTOR and then I tried to somethigs similar, but the result was the same as above:

Code: Select all

//for tab selection
var tabs = application.Ribbon.Children.Single(x => x.GetAccessibleRole() == "PageTabList").As<TabPageList>();
tabs.Children.Single(x => x.As<TabPage>().Title == tabTitle).As<TabPage>().Select();

//for button pressing
application.Ribbon.Buttons.Single(x => x.GetAccessibleName() == btnName && x.Visible).Press();
Can somebody explain why it happens? And how to resolve performance degradation problem?

User avatar
Stub
Posts: 173
Joined: Fri Jul 15, 2016 1:35 pm

Re: CodeJock Toolkit: FindSingle perfomance

Post by Stub » Mon Jun 12, 2017 1:38 pm

Are you testing a debug build by any chance? I just happened to fire our Ranorex tests at a debug build and was startled at the speed difference compared to a release build. Ranorex was suddenly taking a long time (not 50-70s however, just longer than it normally does with a release build) to do anything on our ribbon. Other areas of the application were operating just fine, I didn't notice any slowdown. It's just in the ribbon control.

I just checked in Spy and we have 334 items on our ribbon.

It's slow enough that I wouldn't want to test against a debug build routinely. I was just making sure that I could if I wanted to occasionally.