为什么SeleniumRC CSS定位器可能比XPath慢？
|
我有一些代码可以执行模拟递归树，以使用SeleniumRC从HTML树中抓取内容。我已经使用Xpath和CSS定位器运行代码。
该树表示为一系列嵌套表。如果根本不重要，则某些树内容开始时将不可见，因为分支“已折叠”。对于Xpath和CSS，就可见与不可见而言，树处于相同状态。
为了获得节点值，我的代码以\“ root \”表达式开始，添加\“ branch \”标记，可以为每个连续的同级节点增加该标记，然后使用\“ node \”标记获取文本内容。
都可以，但是使用我想出的CSS表达式要慢得多。
我想这是一种生成定位符表达式的笨拙方法，尽管它对我有用。我只是想弄清楚如何最好地使用CSS来接近使用Xpath所涉及的时代。
循环测试了许多无效的表达式（一直在寻找第n个兄弟姐妹，直到找不到），由于我逐步钻入嵌套表的方式，表达式变得很长。
下面是递归的一些表达式和示例。如果任何人都可以提供关于我正在做的事情的见解，这会使CSS花费比Xpath更长的时间，那将非常有帮助。
我对这种对HTML内容的处理完全是新手，如果您对我从Xpath转到CSS的方式感到有些愚蠢，请这么说。
XPath“令牌”：
final String rootbase = \"//*[contains(@id,\\\"treeBox\\\")]/div\";
// in next string, \"{branchIncrement}\" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = \"/table/tbody/tr[{branchIncrement}]/td[2]\";
final String nodetoken = \"/table/tbody/tr/td[4]/span\";
final String rootbase = \"css=[id*=treeBox]>div\";
// in next string, \"{branchIncrement}\" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = \">table>tbody>tr:nth-child({branchIncrement})>td:nth-child(2)\";
final String nodetoken = \">table>tbody>tr>td:nth-child(4)>span\";
//*[contains(@id,\"treeBox\")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span
//*[contains(@id,\"treeBox\")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[3]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span
[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(3)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span
没有找到相关结果
已邀请:
3 个回复
旦彤
）中进行模式匹配，这需要枚举整个DOM树来定位匹配项，甚至在您从那里下降之前也是如此。考虑一下如何用纯JavaScript编写代码，然后您将开始发现问题。 如果让您感觉更好，则IE仍然没有本机XPath实现，因此Selenium在该浏览器中使用了几种JavaScript实现之一，其运行速度是XPath的二分之一到十分之一。因此，在Firefox 3.6中。 长话短说，在这种特殊情况下，您没有什么能做的更快的CSS定位器。壬驴拿歪竞
爆山
文字替换的XPath包含表达式：CSS包含：文字替换的CSS包含表达式：通过使用两个不同大小的树（一个102个节点，其他1307个节点），我发现了以下内容。 102个节点： |包含|文字| XPath | 15秒| 13秒| CSS | 19秒| 19秒| 1307个节点： |包含|文字| XPath | 255秒| 145秒| CSS | 1893秒| 1811秒| 显然，本机实现（带有Se-RC的Firefox上的XPath）比JScript实现快得多。需要权衡的是，它可能无法在所有浏览器上正常运行。