getElementById() is really slow

VERIFIED FIXED in Future

Status

()

P2
normal
VERIFIED FIXED
20 years ago
11 years ago

People

(Reporter: sspitzer, Assigned: vidur)

Tracking

({dom1, perf})

Trunk
Future
x86
All
dom1, perf
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

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.

Comment 1

20 years ago
But wait, this should only affect you if you are _not_ using XUL documents.
Where are you using vanilla HTML or XML documents?

Comment 2

20 years ago
I didn't realize they used different codepaths for XUL vs. HTML....it looks like
XUL does hash this stuff...

I originally reported this because I noticed a slight speedup on Linux (not
timed, so maybe I only saw it because I was looking for it) when I started
caching the results of getElementById() in JavaScript...

Updating to reflect the status - HTML only.
Here's the offending code:
http://lxr.mozilla.org/seamonkey/source/layout/html/document/src/nsHTMLDocument.cpp#1827
Priority: P3 → P2
Target Milestone: M11
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.

Updated

20 years ago
Whiteboard: [Perf]
(Assignee)

Comment 5

19 years ago
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().
Target Milestone: M11 → M12
Moving to M12.
(Assignee)

Updated

19 years ago
Target Milestone: M12 → M13
(Assignee)

Comment 7

19 years ago
Moving off M12 radar for the time being. One or more might get back once I get a
chance to really look at them.
(Assignee)

Comment 8

19 years ago
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.

Updated

19 years ago
Summary: [PERFORMANCE] getElementById() is really slow → [PERF] getElementById() is really slow

Updated

19 years ago
Keywords: perf

Comment 9

19 years ago
Bulk add of "perf" to new keyword field.  This will replace the [PERF] we were
using in the Status Summary field.
(Assignee)

Updated

19 years ago
Target Milestone: M13 → M14
(Assignee)

Comment 10

19 years ago
Couldn't get this done in time. It'll be first up for M14.

Comment 11

19 years ago
On behalf of PorkJockeys: putting on beta1 radar, per beta criteria priority #2 
- performance. removing extraneous perf tags, cc waterson.
Keywords: beta1
Summary: [PERF] getElementById() is really slow → getElementById() is really slow
Whiteboard: [Perf]

Comment 12

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]

Comment 13

19 years ago
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
Keywords: beta1
Whiteboard: [PDT+]
(Assignee)

Comment 14

19 years ago
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

Comment 15

19 years ago
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

Comment 17

18 years ago
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
Keywords: mozilla1.1
Netscape-Manager-Type-People: Do we need this to meet embedding requirements?
Keywords: nsbeta1
Keywords: dom1
Component: DOM Level 1 → DOM Core
(Assignee)

Comment 19

18 years ago
Fixed by jst@netscape.com prior to XPCDOM landing. The implementation now uses 
a hash table.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 20

18 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

Comment 21

18 years ago
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

Updated

11 years ago
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.