javascript-xpath & IE
Aditya Ivaturi
more appropriate here:
The XPath evaluation on IE (all versions) is excruciatingly slow (at
least for me) when using RC. I searched the forums & there were
suggestion to switch to "javascript-xpath". I did, but it didn't help
at all, well it did but the improvement in speed was for all practical
purpose useless. So I downloaded the javascript-xpath library from the
authors site http://coderepos.org/share/wiki/JavaScript-XPath and
manually inserted it in to the web page of interest & ran my xpath
queries. Surprise, it was blazingly fast - I mean there was absolutely
no comparison!
So my question is very simple - is RC doing something special with
this javascript-xpath library? I am using the Perl driver if that
matters. Why is it so excruciatingly slow in Selenium & blazingly fast
outside? I even checked the version of the library & Selenium is
indeed using the latest available (well it's been the latest for a
while now). So any suggestions as to what is going on? Thanks.
Patrick Lightbody
xpath is being evaluated from a different windows. Apparently the
cross-window talk slows it down big time :(
>
> You received this message because you are subscribed to the Google Groups "selenium-developers" group.
> To post to this group, send email to selenium-...@googlegroups.com.
> To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
>
>
>
Jennifer Bevan
-Jen
Frank Cohen
Frank Cohen, http://www.PushToTest.com, phone 408 871 0122
PushToTest, the open-source test automation company
Twitter: fcohen, LinkedIn: Frank Cohen
Aditya Ivaturi
> (command line flag: -singleWindow, I believe), which eliminates much of the
> slowdown.
finish in this lifetime ;). Anyhoo, I am going to collect some numbers
on different options & may be try to find where the bottleneck is.
Thanks.
PGran...@idc.com
Does anyone know if the new WebDriver core will solve this problem for Selenium?
Also, can you specify single-window mode from the test script? Or must it be specified when you start Sel-RC Server? About 10% of my tests involve multiple windows but if I could specify it for my single window tests I'd still gain a significant performance improvement.
I've had this problem also for sometime and have just "put up with it" due to lack of time but I'd love to have a solution.
Jennifer Bevan <jennife...@gmail.com>
Sent by: selenium-...@googlegroups.com 12/11/2009 10:44 PM
|
|
Jennifer Bevan
As far as the Webdriver core's impact goes, the hypothesis is that it will help, although we do not yet know how much. The discussion so far has basically been to continue with the webdriver integration into Selenium 2.0 and then see what remains to be done to make the multi- vs. single- window performance more comparable.
-Jen
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
Aditya Ivaturi
1) Is there any option within the Selenium server (or in the RC
client) that spits out the time it takes for a command to execute? I
turned on the debug option and there was a lot of info, but nothing
related to execution time of a command. So if there is none, I am
thinking of probably putting in some hooks in the core to capture that
info for me. From a simple perusal, it seems selenium-executionloop.js
might be a good place. Am I looking at the right place?
2) I originally posted this question in response to Patrick's comment
but for some reason the post didn't show up. May be I never hit the
submit button. According to Patrick - "Apparently the cross-window
talk slows it down big time". What I wanted to ask was - why is it not
a problem in FF? Is it because FF has inbuilt XPath evaluator & you
don't have to send data back & forth? If that is correct, then that
means the driver window (in case of IE) requests the HTML from the
target window & processes the XPath (since it has the external XPath
library) & this "chatter" causes the delay? Is that correct?
--aditya
Frank Cohen
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To post to this group, send email to selenium-...@googlegroups.com.
To unsubscribe from this group, send email to selenium-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/selenium-developers?hl=en.
Aditya Ivaturi
> For #1 I recommend you try running your Selenium tests in TestMaker.
your selenium scripts. We have built a whole framework on top of
Selenium for our testing & I was feeling lazy to go through the whole
setup.
Regardless, I was looking in the right place to get the command
execution time. All I did was put in an extra statement in the
_executeCurrentCommand function prototype to add "info" for each
command execution & enable -browserSideLog while starting selenium-
server. This gave me numbers for each command that was executing.
The example command I looked at was - getXpathCount (which we use
heavily in our testing). And since I was running this on my local
laptop with all the crap (read antivirus et.al), for fairness sake
(not statistically valid though) I did three runs for -singleWindow &
the regular dual window option for IE.
XPath query I used - //table[@class='tblList'] - and getXpathCount
will return the count as 17. And in IE with respective options, here
are the execution times in Selenium:
singleWindow - 998ms, 1047ms, 1015ms
dual Window - 54419ms, 55155ms, 57405ms
And using the javascript-xpath library directly on the HTML page in IE
the time it took to parse the same query - 15ms, 21ms, 13ms.
As you can see (from my rather crude experiment), the singleWindow
option in IE actually gives a significant improvement in performance
of XPath processing in IE & the direct use of javascript-xpath is
indeed balzingly fast.
So can any one shed any more light on what is that "chatter" in
Selenium that is slowing things down so much for IE?
PGran...@idc.com
Thanks Jen,
yes, I meant Sel-RC-Java 'test scripts' as actual test programs written in Java. I couldn't remember if those 'hooks' could be put in on a per-test bases.
tnx.
Jennifer Bevan <jennife...@gmail.com>
Sent by: selenium-...@googlegroups.com |
12/14/2009 05:00 PM
|
|
We've put the hooks in for in-test control of multi- vs. single-window mode into the Java RC client, and possibly (I'd have to check) the Python RC client, but you said "test script" -- are you using the HTML tests? If so, I believe you'd have to use the command-line flag "-singleWindow", at least for the time being.
As far as the Webdriver core's impact goes, the hypothesis is that it will help, although we do not yet know how much. The discussion so far has basically been to continue with the webdriver integration into Selenium 2.0 and then see what remains to be done to make the multi- vs. single- window performance more comparable.
-Jen
On Mon, Dec 14, 2009 at 2:36 AM, <PGran...@idc.com> wrote:
- Does anyone know if the new WebDriver core will solve this problem for Selenium?
Also, can you specify single-window mode from the test script? Or must it be specified when you start Sel-RC Server? About 10% of my tests involve multiple windows but if I could specify it for my single window tests I'd still gain a significant performance improvement.
I've had this problem also for sometime and have just "put up with it" due to lack of time but I'd love to have a solution.
Sent by: selenium-...@googlegroups.com 12/11/2009 10:44 PM
|
|
|
Santiago Suarez Ordoñez
yes, I meant Sel-RC-Java 'test scripts' as actual test programs written in Java. I couldn't remember if those 'hooks' could be put in on a per-test bases.
Jen, do you know in detail how is that done? In case you have a patched version of the server, is there a chance your team could spend the time needed to contribute that back to Selenium 1.0? The functionality is valuable, and I have no doubt Selenium 1.0 will coexist with 2.0 much longer than what we'd like.
Santi
Tarun K
"Does anyone know if the new WebDriver core will solve this problem
for
Selenium? "
~ T
Simon Stewart
--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
Jennifer Bevan
http://selenium.googlecode.com/svn/trunk/selenium/src/java/com/thoughtworks/selenium/BrowserConfigurationOptions.java
Make one of these, call .setSingleWindow() on it, and pass it as an argument to start(). I hope that helps,
-Jen
Aditya Ivaturi
> always be sub-optimal because it doesn't have an xpath engine that runs over
> HTML, and so it must always be simulated using IE's (relatively slow)
> javascript engine.
>
Well, this is something that I am unable to wrap my head around & one
of the reasons to start this thread. If you see my comment with the
numbers I posted, simulated XPath using IE's javascript engine wasn' t
"that" slow when used directly. i.e. if I run javascript-xpath on an
HTML page directly (outside of Selenium) the numbers were rather
surprisingly fast. But inside Selenium it becomes exponentially slow.
And I asked this question before & hopefully some one can answer it -
why is it so slow inside Selenium - be it singleWindow or dual window?
Patrick Lightbody
How are you running the xpath expressions "directly (outside of
Selenium)"? We may be comparing apples and oranges here...
Patrick
Aditya Ivaturi
> How are you running the xpath expressions "directly (outside of
> Selenium)"? We may be comparing apples and oranges here...
>
In the HTML page I include the javascript-xpath library & then I
evaluate XPath on page load using a function call.
Patrick Lightbody
details, but I know there at least 2 (and maybe 3) different
libraries. I'd make sure that the one you're including is the same one
that Selenium is indeed using.
Aditya Ivaturi
> Have you tried the various XPath libraries? I forget the exact
> details, but I know there at least 2 (and maybe 3) different
> libraries. I'd make sure that the one you're including is the same one
> that Selenium is indeed using.
>
As far as I know (at least based on the Perl driver's POD) there are 3
options that can be used - default, ajaxslt & javascript-xpath.
"default" option loads the Google's ajaxslt & javascript-xpath uses
Cybozu Labs' library. Google's ajaxslt is definitely slower than
javascript-xpath and so I did my testing with javascript-xpath. I used
the copy that is distributed with the RC & is located in core/xpath of
the slenium-server.jar file. BTW, it is the same version that can also
be found at the original author's site
http://svn.coderepos.org/share/lang/javascript/javascript-xpath/trunk/release/javascript-xpath-latest.js
(v0.1.11).
Patrick Lightbody
avenues. I guess the only next step is for you to get us a simple test
case that demonstrates the slow times in Selenium and fast times when
invoked by clicking on a button. Is that something you might be able
to put together?
Patrick
Aditya Ivaturi
> OK, cool - then it sounds like you've explored all the different
> avenues. I guess the only next step is for you to get us a simple test
> case that demonstrates the slow times in Selenium and fast times when
> invoked by clicking on a button. Is that something you might be able
> to put together?
>
I think I can do that, but I'll have to get to it next week - I am on
vacation from today afternoon.
Aditya Ivaturi
> avenues. I guess the only next step is for you to get us a simple test
> case that demonstrates the slow times in Selenium and fast times when
> invoked by clicking on a button. Is that something you might be able
> to put together?
>
I have a test page ready to demonstrate it. Where can I upload it?
Patrick Lightbody
shoot us a note once you've done so.
Patrick
Aditya Ivaturi
> Easiest thing is to open a bug on code.google.com and attach it, then
> shoot us a note once you've done so.
>
Filed the bug: http://code.google.com/p/selenium/issues/detail?id=307
If you need any further instructions, please let me know.
Sascha
I took your test page to do a little test with a remote Selenium
Server with IE7 in single window mode and the Java client. This is the
code I used:
Selenium s = new DefaultSelenium("sel_host", 4445, "*iexploreproxy",
"http://test_host/test-files/test.html");
s.start();
long start = System.currentTimeMillis();
s.useXpathLibrary("javascript-xpath");
long end = System.currentTimeMillis();
System.out.println("Switched to javascript-xpath in " + (end -
start) + " ms.");
s.open("http://test_host/test-files/test.html");
s.waitForPageToLoad("20000");
start = System.currentTimeMillis();
int count = s.getXpathCount("//table[@class='tblList']/tbody/
tr").intValue();
end = System.currentTimeMillis();
System.out.println("Found " + count + " items in " + (end - start) +
" ms.");
s.stop();
This prints out:
Switched to javascript-xpath in 16 ms.
Found 17 items in 47 ms.
47 ms - 16 ms are 31 ms - that's the time that is needed for the xpath
evaluation. The xpath evaluation in Selenium is not just
document.evaluate, there is some other code run before (checking which
XPath engine to use) and after (converting the NodeList to a Node
array) this.
To run the xpath evaluation directly in the browser it takes 16 ms.
So, I do not see there so much room for improvement in single window
mode.
Sascha
Jennifer Bevan
Regardless of the 2x slowdown for this one test, the experiential single- vs. multi- window performance difference for xpath evaluation is very significant -- in one case here a suite that would take 5 hours in multi-window would take 20 minutes in single-window. So it may be that the simplicity of this test case is producing low numbers, hiding the performance problem -- although 2x is pretty significant if it holds beyond the millisecond range :)
-Jen
Aditya Ivaturi
the page we would end up after a series of tests. I just chose it
because it was the first page we'd end up running the XPath query in
our test suite. So Jennifer's comments might make sense in my case.
Let me do some more tests to confirm & report what exactly I am
observing.
Aditya Ivaturi
> So, I do not see there so much room for improvement in single window
> mode.
>
Damn, I feel much better (well relatively). I missed that you were
testing this in single window mode and even though I did test it in
single window mode, my concern was more for the dual window (which is
the default). Can you run this same test in dual window mode for
comparison? May be I should've pointed it out in the bug I filed.
Aditya Ivaturi
> comparison?
Just for reference here is my test, albeit in perl
use strict;
use warnings;
use Time::HiRes qw(sleep gettimeofday tv_interval);
use Test::WWW::Selenium;
use Test::More "no_plan";
use Test::Exception;
use Data::Dumper;
my $sel = Test::WWW::Selenium->new( host => "localhost",
port => 4444,
browser => "*iexplore",
browser_url => "http://
localhost/" );
$sel->open_ok("/test.html");
$sel->use_xpath_library("javascript-xpath");
$start = [gettimeofday()];
print "XPath matches: ".$sel->get_xpath_count("//table
[\@class='tblList']/tbody/tr")."\n";
$time_spent = tv_interval($start)*1000;
print "Xpath: $time_spent [ms]\n";
And the output:
ok 1 - open, /test.html
XPath matches: 17
Xpath: 204.226 [ms]
1..1
So as you can see definitely worse than single window mode.
Sascha
will never be as fast as singleWindow is. Maybe there is some room for
improvement by reducing the inter-process-communication, but if your
application does not have problems with it you should use the
singleWindow mode.
Sascha
Aditya Ivaturi
> It was about 700 ms in multi window mode. I am quite sure multiWindow
> will never be as fast as singleWindow is. Maybe there is some room for
> improvement by reducing the inter-process-communication, but if your
> application does not have problems with it you should use the
> singleWindow mode.
>
I have to use multiWindow for my application. I want to help if you
guys are busy with other stuff. But, all I need is some document or
some primer on how the selenium server is desinged so that I get a
head start, more specifically what classes launch the browsers & how
the communication happens between these two browser windows. If you
can point me in that direction, I am willing to invest some time in
debugging this. I am not guaranteeing any results, but at least I can
try.
Aditya Ivaturi
filed (http://code.google.com/p/selenium/issues/detail?id=307), every
one was testing with the test page I submitted. Well, that page
includes the javascript-xpath to help test XPath outside of Selenium.
So when I ran a getXpathCount query 100 times I got it done in about
13 seconds, but when I removed that javascript-xpath from the test
page the time jumped to 21 seconds.
So, that brings up an interesting point - is there any way we can can
inject this javascript-xpath file to the test window? I think the
javascript-xpath is loaded only in the driver window. This hack would
definitely improve XPath performance a bit more.
Simon Stewart
the application under test via Selenium?
Simon
Aditya Ivaturi
> Philosophically, the question boils down to: should we be modifying
> the application under test via Selenium?
>
How about letting the user decide that? In this case, for e.g.,
javascript-xpath does nothing for browsers which support DOM 3 XPath
natively and since it is just a script include tag, it does not alter
the behavior of the app under test in any way. If you look hard & long
enough, may be you can find some corner cases where this could
interfere with the app under test (may be namespace collision, which I
seriously doubt but just throwing it out there), but that is where we
let the user decide whether they want to include it or not for
performance reasons. And there is significantly noticeable
improvements in XPath processing if we do that.
Aditya Ivaturi
I might have stumbled on another way to squeeze out some more
performance from the XPath processing on IE. I posted this on the
users forum http://groups.google.com/group/selenium-users/browse_thread/thread/e5bb0fda67f06182
hoping some one might know how to accomplish that through Selenium. To
test my theory, in the issue #307's test.html I modified the main()
function to test the XPath with & without context nodes of the table.
Here is the script:
function main() {
var expr = ".//tbody/tr";
var start_ = new Date();
var tblNode = document.evaluate('//table[@class=\'tblList\']',
document, null, 9, null).singleNodeValue;
for (var i=0; i<100; i++)
{
var result = document.evaluate('//table[@class=\'tblList\']/tbody/
tr', document, null, 6, null);
//var result = document.evaluate(expr, tblNode, null, 6, null);
}
alert('Found ' + result.snapshotLength + ' rows in ' + (new Date() -
start_) + ' [ms]');
};
I uncomment the respective for each run. So when I run the XPath
without using the table context node - document.evaluate('//table
[@class=\'tblList\']/tbody/tr', document, null, 6, null) the time for
execution to complete was 283ms but when I used the table context node
& used relative XPath document.evaluate(expr, tblNode, null, 6, null)
- the time dropped to 203ms.
The above test was of course done outside of Selenium but I am fairly
positive that we can get better improvements in XPath processing for
IE in Selenium (for multiWindow) if we can do two things :
1) Inject javascript-xpath in app under test window
2) Somehow facilitate context nodes usage for XPaths - this will be
very helpful especially if your pages are huge.
Sascha
Identifier to the table node. Then use an XPath like //table
[@id='...']/tbody/...
Xpathes that start with an ID selection are usually faster in IE as
Javascript XPath can use the native method getElementById to get it.
This should be something similar as the context node. The Selenium API
does not support the concept to return an Element reference to your
client (in comparison to WebDriver where you have your WebElement).
Sascha
On Jan 13, 1:27 am, Aditya Ivaturi <ivat...@gmail.com> wrote:
> Apart from injecting "javascript-xpath" in the target window, I think
> I might have stumbled on another way to squeeze out some more
> performance from the XPath processing on IE. I posted this on the
> users forumhttp://groups.google.com/group/selenium-users/browse_thread/thread/e5...
Aditya Ivaturi
> Selenium has a method called assignId. You may try to assign an
> Identifier to the table node. Then use an XPath like //table
> [@id='...']/tbody/...
>
> Xpathes that start with an ID selection are usually faster in IE as
> Javascript XPath can use the native method getElementById to get it.
> This should be something similar as the context node. The Selenium API
> does not support the concept to return an Element reference to your
> client (in comparison to WebDriver where you have your WebElement).
>
> Sascha
>
Even if we use ids for the element nodes, context nodes would still be
faster for those nodes with ids. But, I definitely understand that
architecture of Selenium is such that it doesn't provide reference
back to the client. So I guess, I am off to dig some more :).
Aditya Ivaturi
that I did and its results - http://code.google.com/p/selenium/issues/detail?id=307#c8.
In short, if I introduce a little more complexity in my XPath without
the javascript-xpath library avaialable for the app under test, the
performance is almost 23 times or 2213% worse! Am I doing some thing
wrong to achieve these wild numbers?
gyrm
I've been working on an alternative XPath engine over the past few
days, supported by refactoring some code in Core so that it (and other
future implementations) can be plugged in. The "new" engine delegates
to an existing engine (i.e. ajaxslt or javascript-xpath) for actual
evaluation; however, it has the following interesting characteristics,
specifically for optimizing multi-window mode by avoiding cross-window
RPC latency:
- It makes a mirror copy of the document in the remote window to a
frame in the local Selenium window. It uses this "test copy" to
construct an optimized expression for locating the desired element in
the remote window. For element counting, the remote window isn't even
consulted.
- It makes heavy use of caching, to avoid unnecessary document copies,
expression optimization, and actual evaluation. In particular, once
found, nodes are cached - until they become invalidated. Caches are
bounded in size.
- It uses jQuery for the purpose of parsing innerHTML content and
transforming it into DOM nodes for insertion into the mirror document.
Because we don't want to be evaluating application scripts in the
Selenium window, <script> elements are not included among the inserted
nodes. Therefore, this engine will not work for XPath's that look for
or include script element paths.
I'd like to welcome everyone to test out the new engine, which is NOT
turned-on by default. I don't have any extensive real world tests at
my disposal, so your numbers would be VERY informative for me -
especially in juxtaposition to numbers from using plain-old javascript-
xpath . If you pull the latest from the repo and build the Selenium
server (instructions here:
http://groups.google.com/group/selenium-developers/browse_thread/thread/c3e06311c9400145),
you should have it. But you will need to copy the engine
implementation file rpc-optimizing-user-extension.js and either add it
to the server server jar (I've been using
HAW BIN@HAWBIN-2b300780 /cygdrive/i/work/selenium-merged/common/src/js
$ jar uf ../../../build/selenium-server-standalone.jar core/scripts/
user-extensions.js
), or specify it with the -userExtensions switch.
Let me know what ya'll find out. :)
Haw-Bin
On Jan 13, 8:16 pm, Aditya Ivaturi <ivat...@gmail.com> wrote:
> If you guys haven't already lost patience :), here is another test
> that I did and its results -http://code.google.com/p/selenium/issues/detail?id=307#c8.
Aditya Ivaturi
this post. But I do have a questions regarding this change:
- What happens if the page uses ajax & constantly updates its data or
even layout? How, will this new change affect the XPath queries since
it is now going to be run against a copy? Let us say, if my test suite
includes first finding a button using XPath, then clicking it & then
find something else on that same page using XPath, how will the new
change handle that?
--aditya
On Jan 13, 8:34 pm, gyrm <hbc...@gmail.com> wrote:
> Thought I'd share ...
>
> I've been working on an alternative XPath engine over the past few
> days, supported by refactoring some code in Core so that it (and other
> future implementations) can be plugged in. The "new" engine delegates
> to an existing engine (i.e. ajaxslt or javascript-xpath) for actual
> evaluation; however, it has the following interesting characteristics,
> specifically for optimizing multi-window mode by avoiding cross-window
> RPC latency:
>
<snip>
Aditya Ivaturi
even horrible numbers with the new code. So let me list out what I am
doing to verify that I am doing it right:
1) Downloaded the latest source from http://selenium.googlecode.com/svn/trunk/.
I am at r8081.
2) In trunk run this command - rake selenium-server-standalone.
3) Copy common\src\js\core\scripts\rpc-optimizing-user-extension.js to
the build directory & rename it to user-extensions.js
4) java -jar selenium-server-standalone.jar -userExtensions user-
extensions.js.
5) I am using the same test page that I submitted to issue #307.
6) Here is my Perl test script:
<code>
use strict;
use warnings;
use Time::HiRes qw(sleep gettimeofday tv_interval);
use Test::WWW::Selenium;
use Test::More "no_plan";
use Test::Exception;
#use Data::Dumper;
my $sel = Test::WWW::Selenium->new( host => "localhost",
port => 4444,
browser => "*iexplore",
browser_url => "http://
localhost/" );
my ($start, $end, $time_spent) = 0;
$sel->use_xpath_library("javascript-xpath");
$start = [gettimeofday()];
for (my $i=0; $i < 100; $i++)
{
$sel->get_xpath_count("//table[\@class='tblList'][1]/tbody/tr");
}
$time_spent = tv_interval($start)*1000;
print "Xpath: $time_spent [ms]\n";
$sel->close();
</code>
and here is my output:
ok 1 - open, /test.html
Xpath: 503481.153 [ms]
1..1
So it took almost 503 seconds to query "//table[\@class='tblList'][1]/
tbody/tr" 100 times. Am I doing some thing wrong?
gyrm
Thanks for trying it out.
The extension doesn't replacement "javascript-xpath" - it actually
adds a new engine called "rpc-optimizing". So try to set that with
your call to use_xpath_library() .
As far as AJAX page updates, the engine doesn't permanently cache a
mirrored copy of the document. It always compares against the
innerHTML of the original*. If the markup in the original document
changes, it will update the mirrored copy - otherwise it won't. I am
happy to hear your experiences with AJAX changes, though, as I haven't
tested this myself yet.
Haw-Bin
*It's not a direct HTML-to-HTML comparison, because the copy may have
some <script> tags stripped out. Thus, the comparison goes through a
mapping from original to copy that is cached.
On Jan 14, 4:04 pm, Aditya Ivaturi <ivat...@gmail.com> wrote:
> Haw-Bin - may be you & I are doing some thing different because I got
> even horrible numbers with the new code. So let me list out what I am
> doing to verify that I am doing it right:
>
> 1) Downloaded the latest source fromhttp://selenium.googlecode.com/svn/trunk/.
Aditya Ivaturi
100 times for //table[\@class='tblList'][1]/tbody/tr in IE and it
finished in 12 seconds. That is very much close to FF performance. But
FF takes a very slight hit in performance. Without rpc-optimizing, FF
completes the same task in about 3.5 seconds but took about 5.3
seconds with the new fix, which actually makes sense. So, I guess this
new fix should be used only with IE. I am going to run this on our
internal testsuite & report the results back.
Santiago Suarez Ordoñez
Please keep us updated.
Santi
Aditya Ivaturi
over 800 tables (yeah, our app abuses the tables at will :)).
Regardless, close to 125 //table queries (with some dynamically
generated filters) are run & it used to take close to 25 minutes with
javascript-xpath to finish in IE. Now, that time has dropped down to
under 4 minutes. In the course of testing, I also realized that I can
improve some routines in my Perl code to further improve that time (I
am still working on it).
On a side note, I also tried to offload my XPath query processing to
JavaScript directly using user-extensions and that allowed me to use
context nodes, which actually provides me performance close to or even
better than FF (with queries from Perl driver). But, you have to
realize that these are very specific set of XPath queries that are
specific to that page like the one with over 800 tables. So all in
all, I can mix & match these two solutions to gain a considerable
improvement in execution time on IE.
Obviously, it begs the question - will this new "rpc-optimizing"
option be available only through user-extensions?
gyrm
I fully intend to fold rpc-optimizing into Core - I thought it would
be a good idea to vet it as an extension first. My only concern is
with the jQuery dependency - it should be somehow hidden from the
application under test, such that it doesn't conflict with or clobber
other instances of jQuery or any other js framework. I haven't done
any testing in this area yet, and am not sure what the best approach
might be.
Haw-Bin
Adam Goucher
scriptaculous (1.6.1) in core as dependencies. How are their inclusion /
impact mitigated. One of the things on my 'to explore' list was how to
update them to a current version (1.6.1 for prototype and 1.8.3 for
scriptaculous) as they are each almost 5 years old.
Does this mean we would have jQuery /and/ prototype in a future core?
-adam
Aditya Ivaturi
support for CSS locators 1-3. So does that mean the, theoretically at
least, you don't need to include cssQuery library with the core any
more.
gyrm
parsing and appending HTML, without introducing it as a visible
dependency in Selenium and without impacting end users ... which is to
say I'm not too interested in replacing the cssQuery library just for
this.
Right now I'm thinking of either extracting just the bits of jQuery
required for the limited functionality I need, OR creating some kind
of wrapper class that completely encapsulates the jQuery object, and
exposing a couple of methods that simply delegate to jQuery. Or maybe
some hybrid of these two approaches.
Haw-Bin
Aditya Ivaturi
release in mind when this fix will be officially provided?
gyrm
these days, after the merge into Google code. At any rate, it will
show up in the next release. I just changed it from being an extension
to being included in Core last night.
Haw-Bin
Patrick Lightbody
gyrm
couplet of "rpc-optimizing-ajaxslt" and "rpc-optimizing-jsxpath",
INSTEAD of "rpc-optimizing". This way, you can choose which actual
engine you want to back the optimization logic.
Haw-Bin