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

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

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

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

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

Johnny, did you actually do this recently?

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.

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.

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.

I'll take this

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?

(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.

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.

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.

(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?

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).