[Webkit-unassigned] [Bug 13021] New: XPath can be very slow

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=13021

           Summary: XPath can be very slow
           Product: WebKit
           Version: 522+ (nightly)
          Platform: Macintosh
               URL: http://ejohn.org/apps/classname/xpath.html?r0=1173429259
        OS/Version: Mac OS X 10.4
            Status: NEW
          Severity: Major
          Priority: P2
         Component: XML DOM
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: bdash at webkit.org


After reading <http://ejohn.org/blog/getelementsbyclassname-speed-comparison/>
I grabbed a copy of the test pages to see how we compared to Firefox.  Our
results on the XPath test (at
http://ejohn.org/apps/classname/xpath.html?r0=1173429259) are horrible.  We
frequently take 20+ seconds, while Firefox comes in at around 5 seconds.

The document uses prototype.js's getElementsByClassName implementation, which
will use XPath if available.  It constructs a path of the form
".//*[contains(concat(' ', @class, ' '), ' " + className + " ')]", where
className is the class being searched for.

A quick glance at the process with Shark suggests we're spending a lot of time
dispatching DOM subtree modified events (XPathResult attaches a listener for
these) from below Attribute::createAttrIfNeeded.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.