to quote alecf: "getElementById() is really slow in gecko's implementation. it actually walks the _entire_ DOM" we are using getElementById() in the js that makes up our app: http://lxr.mozilla.org/seamonkey/search?string=getElementById if we can speed it up, it would help all over the place.
But wait, this should only affect you if you are _not_ using XUL documents. Where are you using vanilla HTML or XML documents?
Triage: setting this as with a TFV of M11, and a priority P2, since it's an HTML DOM 0 bug.
HTML DOM bugs are M11/P2 for Vidur.
No question about it - we should be hashing the id. I already do that for named HTML items and just didn't update the first pass implementation of getElementById().
Moving to M12.
Moving off M12 radar for the time being. One or more might get back once I get a chance to really look at them.
In an attempt to get my bug list in order again, marking all the bugs I have currently as ASSIGNED.
Summary: [PERFORMANCE] getElementById() is really slow → [PERF] getElementById() is really slow
Bulk add of "perf" to new keyword field. This will replace the [PERF] we were using in the Status Summary field.
Couldn't get this done in time. It'll be first up for M14.
On behalf of PorkJockeys: putting on beta1 radar, per beta criteria priority #2 - performance. removing extraneous perf tags, cc waterson.
Summary: [PERF] getElementById() is really slow → getElementById() is really slow
Putting on PDT+ radar for beta1.
this is not critical for beta1. it only affects large, DOM-intensive, *HTML* documents. if somebody thinks otherwise, please re-add the beta1 grafitti.
Component: DOM Level 0 → DOM Level 1
This bug shouldn't move any further than M16 (says the man who's going to be gone when M16 is worked on :-)). Johnny, look at the implementation for NamedItem. That implementation does maintain a hash table that it keeps in sync with the document. It doesn't create the hash until the document has completed loading, though. Unfortunately, most calls to these methods are probably during loading. Maybe we can do better...
Target Milestone: M14 → M16
M16 has been out for a while now, these bugs target milestones need to be updated.
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M16 → Future
Considering that getElementById() is the recommended method of mozilla&&netscape to overcome IE/NS specific html and will be used a lot more in the future it shouldn't put be to far out. Adding mozilla1.1 keyword
Netscape-Manager-Type-People: Do we need this to meet embedding requirements?
Fixed by email@example.com prior to XPCDOM landing. The implementation now uses a hash table.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala
verified it on both IE and netscape ...did not see any considerable difference in the amount of time it took for displaying the Elements-by-Id
Status: RESOLVED → VERIFIED
Component: DOM: Core → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.