Performance for FindSingle(..)

Technology specific object identification, supported applications, web technologies, and 3rd party controls.
gisiman
Posts: 8
Joined: Sat Jan 02, 2010 6:34 pm

Performance for FindSingle(..)

Post by gisiman » Sun Jan 03, 2010 9:35 pm

I'm testing trial version 2.2 (Dev env: WinXP SP3, VS2008, WebTestPureAPI)
I have a performance issue with following:

Code: Select all

 // Call explorer.exe
System.Diagnostics.Process.Start("iexplore.exe", "www.ranorex.com/web-testing-examples");

WebDocument webDoc = "/dom[@caption='Ranorex Test Page']";
webDoc.Navigate("http://www.korail.com/2007/mem/mem01000/w_mem01100.jsp");
webDoc.WaitForDocumentLoaded();

// so slow...take many seconds
InputTag tagMember = webDoc.FindSingle(".//input[@name='txtMember']");
InputTag tagPwd = webDoc.FindSingle(".//input[@name='txtPwd']");
Is there a solution to make this faster?

User avatar
Ciege
Ranorex Guru
Posts: 1335
Joined: Thu Oct 16, 2008 6:46 pm
Location: Arizona, USA

Re: Performance for FindSingle(..)

Post by Ciege » Mon Jan 04, 2010 5:56 pm

How many is "several" seconds?
How complex is this page? Do you have many other controls or elements on the page? Are these tags you are looking for buried deep within other frames or containers?

If the controls are deep within the page and you are starting your search from the root of the document object it may indeed take some time to traverse through the higher level elements before it finds the ones you are looking for.
If it is indeed an issue with the objects being very deep and living within other containers you can try getting a reference to the container in which the elements live in, then starting your search from within that container.

Just a guess without being able to see exactly how complex a web page you are interacting with.
If this or any response has helped you, please reply to the thread stating that it worked so other people with a similar issue will know how you fixed your issue!

Ciege...

gisiman
Posts: 8
Joined: Sat Jan 02, 2010 6:34 pm

Re: Performance for FindSingle(..)

Post by gisiman » Mon Jan 04, 2010 7:51 pm

Thanks Ciege!.

In my case. target Input text's full path is this:
//body/div[@id='wrapper']/div/div/div[@id='center']/form[@name='form1']/table/tbody/tr/td/table[3]
/tbody/tr[2]/td/table/tbody/tr[2]/td/table/tbody/tr/td[1]/table/tbody/tr[1]/td/table/tbody/tr[1]
/td[@innertext='  ']/input[@name='txtMember']
very deep~ :cry:

what can I do?

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Performance for FindSingle(..)

Post by Support Team » Wed Jan 06, 2010 9:53 pm

gisiman wrote:what can I do?
As ciege already said: First search for a common parent element (e.g. "form1" or a "tbody" tag deeper in the hierarchy) and then always search relatively from this container element.

Another thing you can do is to create a Ranorex cache session for every web page. Using a cache session Ranorex retrieves all information only once from the Internet browser directly (usually a slow operation), stores all data in an internal cache and from then on only uses the stored data (quick). The bad thing is that as long as the cache session is active, you always get the same data, i.e. the data Ranorex stored on the first access to the element. So, whenever the web site changes, you need to end the cache session to get the up-to-date data:
// create a new cache session
using (new CacheSessionContext())
{
    // first search will still be slow
    InputTag tagMember = webDoc.FindSingle(".//input[@name='txtMember']");
    // all following search operations should be much quicker
    InputTag tagPwd = webDoc.FindSingle(".//input[@name='txtPwd']");
}
// cache session ended
Are you working with Internet Explorer? Automation of Internet Explorer (IE) is currently (Ranorex 2.2) much slower than automating Firefox, since the communication with IE takes much more time. We are currently implementing a IE plugin that will speed up the communication, thereby speeding up automation in IE to the level in Firefox.

Regards,
Alex
Ranorex Support Team
.
Image