Closed Bug 143191 Opened 22 years ago Closed 20 years ago

Investigate splitting up nsContentList into multiple classes

Categories

(Core :: DOM: Core & HTML, defect, P4)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

(Keywords: helpwanted, memory-footprint, perf) 

nsContentList currently uses _either_ mMatchAtom/mMatchNamespaceId _or_
mMatchFunc/mData; things like Match() branch on that difference, and different
constructors are used for the two types of content lists.  This strongly
suggests that we should just have two separate classes, both of which should be
able to be smaller and faster as a result of having fewer members and having to
do fewer checks.

I'll investigate this sometime soonish, hopefully...
Keywords: footprint, perf
Priority: -- → P1
Target Milestone: --- → mozilla1.1beta
QA Contact: desale → stummala
Target Milestone: mozilla1.1beta → mozilla1.2beta
Blocks: 162927
Target Milestone: mozilla1.2beta → mozilla1.3beta
Target Milestone: mozilla1.3beta → Future
Target Milestone: Future → mozilla1.5beta
I've not thought of a decent way to do this yet.  Futuring, and I doubt I will
ever get to this.  It's not clear to me that the benefits of doing it, if any,
are worth it.
Keywords: helpwanted
Priority: P1 → P4
Target Milestone: mozilla1.5beta → Future
Now that getElementsByAttribute() uses this class, comment 0 is no longer true.
 There are no real benefits to splitting up at this point.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
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.