Why is Selenium InternetExplorerDriver Webdriver very slow in debug mode (visual studio 2010 and IE9)

[Jon Spokes]

I'm using the example code from the SeleniumHq site - but in debug
mode the performance is awful.
In release mode the entire test takes about 6 seconds (including
launching and closing IE) In Debug mode it takes 65 seconds ?

I'm using .Net 4 and the latest version (2.16) of the webDriver.dll,
running on 64bit windows 7

I've tried it in ie8 and have the same performance. Firefox is fine -
but my clients use IE so I'm stuck with testing against it. Also - I
don't have the same issues if I use Selenium RC.

Does anyone else get this behaviour - or if not are you on the same
version dlls as me ?

[Jon Spokes]

It seems to be related to running in 64bit mode - if I force the
project back into x86 mode it runs fine

[Mike Riley]

That makes sense, because switching between 32-bit and 64-bit mode is
very slow.

Mike

[Jon Spokes]

No, that doesn't make sense. When my application runs in 64bit mode it
launches a 64bit version of InternetExplorer , and when it runs in
32bit mode it launches a 32bit version of InternetExplorer.

There should be no 'switching' going on?

[Jim Evans]

I use 64-bit IE almost exclusively when developing the .NET bindings,
and I'm not seeing what you are. 64-bit IE is considerably slower than
32-bit IE under WebDriver for IE 9, but most of that can be traced to
JavaScript engine differences[1] as the IE driver relies heavily on
JavaScript to perform its work. Nevertheless, I'm certainly not seeing
an order of magnitude slowdown between 32- and 64-bit versions.
Perhaps some analysis of what your code is doing might provide some
context[2].

--Jim

[1] IE 9 got a new JavaScript engine, Chakra, that brought its
performance to respectable, but that engine was only implemented in 32-
bit IE. 64-bit IE retained the old engine with its comparatively poor
performance.
[2] Some operations, like getting the text of an element, are much
more computationally expensive than others in the JavaScript code
executed.

[Jon Spokes]

I'm pretty much using the sample code off the website

IWebDriver driver = new
OpenQA.Selenium.IE.InternetExplorerDriver();

//Notice navigation is slightly different than the Java
version
//This is because 'get' is a keyword in C#
driver.Navigate().GoToUrl("http://www.google.com/");
IWebElement query = driver.FindElement(By.Name("q"));
query.SendKeys("Cheese");
System.Console.WriteLine("Page title is: " + driver.Title);
// TODO add wait
driver.Quit();

I've downloaded the latest 2.17.0.0 version earlier - and I'm still
getting the poor performance with x64 in debug mode. As I said above :
Working in release mode is fine and working in debug mode in x86 is
fine. It's just x64 debug mode that crawls ?

What versions of the dll's are you using ?

[Jon Spokes]

I’ve downloaded the source, and had a quick dig

It seems to be spending all its time in
HttpCommandExecutor.CreateResponse
On line 106

webResponse = (HttpWebResponse)request.GetResponse();

The request looks like

? request
{System.Net.HttpWebRequest}
    [System.Net.HttpWebRequest]: {System.Net.HttpWebRequest}
    base {System.MarshalByRefObject}: {System.Net.HttpWebRequest}
    AuthenticationLevel: MutualAuthRequested
    CachePolicy: {Level:BypassCache}
    ConnectionGroupName: null
    ContentLength: 31
    ContentType: "application/json;charset=utf-8"
    Credentials: null
    Headers: {Accept: application/json, image/png
Content-Type: application/json;charset=utf-8
Host: localhost:52616
Content-Length: 31
Expect: 100-continue

}
    ImpersonationLevel: Delegation
    Method: "POST"
    PreAuthenticate: false
    Proxy: {System.Net.WebRequest.WebProxyWrapper}
    RequestUri: {http://localhost:52616/session/a69b1117-6025-4d7b-
a91c-342f9afac35c/url}
    Timeout: 60000
    UseDefaultCredentials: false

The Response (when it comes back) is

{System.Net.HttpWebResponse}
    base {System.Net.WebResponse}: {System.Net.HttpWebResponse}
    CharacterSet: "UTF-8"
    ContentEncoding: ""
    ContentLength: 77
    ContentType: "application/json; charset=UTF-8"
    Cookies: {System.Net.CookieCollection}
    Headers: {Vary: Accept-Charset, Accept-Encoding, Accept-Language,
Accept
Connection: close
Accept-Ranges: bytes
Content-Length: 77
Content-Type: application/json; charset=UTF-8

}
    IsMutuallyAuthenticated: false
    LastModified: {1/18/2012 2:59:27 PM}
    Method: "POST"
    ProtocolVersion: {1.1}
    ResponseUri: {http://localhost:52616/session/a69b1117-6025-4d7b-
a91c-342f9afac35c/url}
    Server: ""
    StatusCode: OK
    StatusDescription: "OK"
    SupportsHeaders: true

The actual browser instance displays the page almost instantly, but
then the code just sits on that line doing something ?

[Jim Evans]

Okay, so GetResponse() is a method in the .NET Framework itself, so
you're out of the realm on C#, and into the C++ code that forms the
common core of the IE driver. Since the issue you're having is in
navigating to a page, I'd suspect the issue to be somewhere in the
code that detects when IE is finished navigating[1]. Having said that,
I haven't experienced any order-of-magnitude performance differences
in that code either, with respect to 32-bit vs. 64-bit. I'm almost
always using the HEAD revision of the Subversion repository.

I wonder if the problem would resolve itself using an out-of-process
HTTP server component. I've been experimenting with such an
architecture change, but it's a fairly extensive one that I can't just
post how to modify it to work that way. I know I'm not being much help
here, but I do use an environment identical to yours as you've
described it thus far, and I'm just not experiencing what you are.

--Jim

[1] The method in question is Browser::Wait(), and is starts at or
around line 263 of Browser.cpp in the IEDriver project.

[Jon Spokes]

Thanks for that - it sounds like it's probably down to something
specific to my machine or setup. I'll try some of the other devs here
and see if it's a problem for them. Failing that I may just run my
tests using x86 - our clients are aren't going to be using 64 bit
browsers for some years yet.