75435 - Improve getElementById() performance for XML documents

Status: RESOLVED FIXED

(Core :: XML, defect, P4)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Copy the tactics (but not impl) from HTML document - make a hash table of IDs
for fast access.

Comment 1

[rbs]

XUL seems to have its own improved way of handling this.

Comment 2

[Julien Cegarra]

getElementById() performance was fixed with the bug #14001 (closed on
2001-07-18), so we could close that one now.

/jc

Comment 3

[Heikki Toivonen (remove -bugzilla when emailing directly)]

It was fixed only for HTML. This bug is about XML. Other slow implementations of
getElementById() are XUL and possibly RDF.

Comment 4

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This is not used in chrome nor are you normally going to be using this, futuring
for now to concentrate on more pressing issues.

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Johnny, did you actually do this recently?

Comment 6

[Johnny Stenback (:jst)]

No, not really. I consolidated some of the code that does the ID matching with
the HTML code, but speed wise we're still the same. We'll need a hashtable or
somesuch behind this to make it fast, and that's still not done.

Comment 7

[Todd A. Fisher]

Attachment: Test to compare performance between getElementById and XPath

I've noticed mozilla's getElementById is significantly slower then opera and safari.  It's faster then IE 6.0, but only a little.  It sure would be nice if it could be speed up to match the other two browsers.

Comment 8

[tor]

Attachment: first cut at moving id hash to nsDocument

This moves the id hash from nsHTMLDocument to nsDocument.  As I tried to leave all the logic dealing with "name" in nsHTMLDocument, the implementation details of the hash are exposed to inheritors of nsDocument.

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'll take this

Comment 10

[Jonathan Watt [:jwatt]]

This is responsible for a lot of the slowness in SVG, so setting blocking1.9? Any chance the patch could be finished off in time Jonas?

Comment 11

[tor]

(In reply to comment #10)
> This is responsible for a lot of the slowness in SVG, so setting blocking1.9?
> Any chance the patch could be finished off in time Jonas?

Do you have testcases which show getElementById being the issue in profiles?  I'd like to see them - usually my profiles of SVG show cairo and the X server being the problem points.

Comment 12

[Jonathan Watt [:jwatt]]

Sure. Basically anything with lots of gradient/pattern/clipPath/etc. references in it. See bug 336647 comment 5, for example, where I note the time spent under MatchElementId is almost as long as the same as the time spent under Paint! I remember going through some of the slower SVGs on openclipart.org and MatchElementId consistently showing up high in profiling, so that would be a good place to start.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not going to have time to work on this :(

However it should be possible to do this in a safe enough way I think, so if someone can come up with such a patch I should be able to review. It would have to happen within a few weeks though.

Comment 14

[tor]

(In reply to comment #12)
> Sure. Basically anything with lots of gradient/pattern/clipPath/etc. references
> in it. See bug 336647 comment 5, for example, where I note the time spent under
> MatchElementId is almost as long as the same as the time spent under Paint! I
> remember going through some of the slower SVGs on openclipart.org and
> MatchElementId consistently showing up high in profiling, so that would be a
> good place to start.

Paint server lookup used to be a horrible abuser of MatchElementId, true, but that was fixed in the rewrite of the SVG rendering code since FF1.5/2.0.  Have you seen this behavior reappear in current builds?

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I fixed this in bug 344258. XML documents (in fact all documents) now use the same logic as HTML documents (which was moved to nsDocument).