I am seeing this too. Any updates?

You need to use at the 64-bit IEDriverServer.exe if you're using 64-bit IE, or the 32-bit
IEDriverServer if you're using 32-bit IE.

I am using 64bit 2.25.3 version.  

You need to use the 32 bit version of the IEDriverServer.exe if you are using the 32
bit IE client (which most people do). You may have a 64bit machine but you wouldn't
ordinarily use a 64bit version of IE. Download and use the 32bit version and see.

Matt.

Thanks a lot Matt. I even don't think about that possibility, because Win8 and everything
that connect to this OS is less informative that anything in the world. So I installed
x32 driver and everything go much smoothly and I can see something after login screen
:)

Well, I cannot agree on Matt's comment.
His answer is right from point "how it should work" but not "how it is in real" :).
A scenario where I use IEDriver 64bit with IE x64 under Win8 x64 does NOT work as well.
When I use IEDriver x32 with IE x64 + Win8 x64 - works fine though.

So, it looks like IEDriver x64 performance issue.

P.S. Win2008 R2 - same result.

Great Thanks Matt!

I am having this same issue on Windows 7. I have both IE x64 and x86 versions running
on my machine. The same test of sendkeys takes about 2 seconds in x86 but about 25
seconds in x64. It is just setting the word selenium in a google search. This appears
to be a problem with the driver

Same problem. But is seems to be related to the fact that there are either uppercase
& digits types. If only lowercase characters are typed, it goes much faster. 
We use the 32 bits version of the driver on WinXP 32 bits OS , IE 8

Problem with the driver, but these issues (performance on IE) are open since a long
time and are not investigated / fixed. 

It makes Selenium / Webdriver barely unusable for projects that require testing on
IE ...

Something in the way 64-bit IE processes externally sent mouse and keyboard messages
from the Windows SendMessage API seems to be causing the issue. The IE driver is using
the API correctly. You have three choices when encountering this problem.

First, you can use the 32-bit driver. This should be the correct solution for the vast
majority of cases. Most users end up using 32-bit IE anyway, even if Windows is 64-bit.

Second, you can disable native events. See your language binding documentation for
the exact syntax on how to do this in your preferred language. You will probably sacrifice
some measure of accuracy with element event firing, but it will solve this particular
performance issue.

Third, you can use the "requireWindowFocus" capability. This uses a different method
for simulating mouse and keyboard input, and will likely see better performance. Additionally,
its method of simulation is more accurate than the default IE driver input methods.
The drawback is that the method requires the IE window to be in the foreground, and
the driver will continually attempt to bring IE into the foreground. 

As an aside, and in direct response to comment 11, if you have issues with the driver,
and you are unhappy with the attention your issue appears to be receiving, I remind
you of two things. First, the contributors to the project are largely unpaid volunteers,
and one would do well to remember that when one accuses them of shirking responsibility.
Second, the code to the IE driver, and indeed the entirety of the project is fully
available. There is nothing preventing you from debugging and patching the issue yourself.
We've even made it easier to submit those patches back to the project by mirroring
 it on GitHub, and utilizing its pull request mechanism.

requireWindowFocus don't work for me. After start of browser it dosn't recive focus
on first keyboard input (Clear then SendKeys). Second chain of Clear and SendKeys work
fine.
Env:
IEDriverServer 2.35.3
Windows 8
C#bindings 
Nunit 2.6.2
VS 2012

I would say option1 of using 32bit IEdriver is better way to move ahead as it works
in majority of cases. it resolved my issues as discussed above.

Issue 6003 has been merged into this issue.

Even I had faced the same issue but using 32 bit IEDriverServer solved my problem thanks
mattd

Marking this as a duplicate of issue #5116. The root cause is the same, but that bug
(even though later) has a much fuller, more complete analysis of the problem and what
it would take to resolve it.

Same issue is still there as of today, after 4 years (changing engine to x86 == all
OK, x64 == superslow).

Use IE 32 with IE10 32 bit work properly.