Closed
Bug 105071
Opened 23 years ago
Closed 23 years ago
nsXULElement should use nsCheapVoidArray for its children
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
FIXED
mozilla0.9.6
People
(Reporter: waterson, Assigned: waterson)
References
Details
(Keywords: memory-footprint)
Attachments
(2 files)
1.50 KB,
patch
|
brendan
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
2.46 KB,
patch
|
Details | Diff | Splinter Review |
nsXULElement uses nsVoidArray for its children, which burns two words due to the
nsVoidArray's vtable. We should use nsCheapVoidArray (which rjesup is moving to
XPCOM and renaming nsSmallVoidArray) to save a word here.
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
Comment on attachment 53761 [details] [diff] [review]
use nsCheapVoidArray instead of nsVoidArray in nsXULElement
sr=jst
Attachment #53761 -
Flags: superreview+
Comment 3•23 years ago
|
||
Comment on attachment 53761 [details] [diff] [review]
use nsCheapVoidArray instead of nsVoidArray in nsXULElement
r=brendan@mozilla.org
Attachment #53761 -
Flags: review+
Comment 4•23 years ago
|
||
r=rjesup@wgate.com
Note that this may or may not actually save us any space, depending on the
allocation granularity and the previous/new size of nsXULElement (or subclasses
thereof). I'm sure everyone here knows this, of course. Also, it probably cost
will cost us space if it's common for nsXULElements to have more than 1 child.
If the distribution is heavily weighted to 0 elements and 1 element isn't too
much more frequent than the larger values, then nsVoidArray * is more
appropriate for CPU use reasons.
What's the distribution of children of nsXULElements?
Assignee | ||
Comment 5•23 years ago
|
||
Assignee | ||
Comment 6•23 years ago
|
||
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•