Closed Bug 156364 Opened 23 years ago Closed 23 years ago

Add storage for flags in nsGenericElement

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.1beta

People

(Reporter: jst, Assigned: jst)

References

Details

(Whiteboard: [HAVE FIX, CHECKMEIN])

Attachments

(2 files, 1 obsolete file)

nsGenericElement needs flags so that we can start optimizing what's stored in the elements and what's stored elsewhere, and we'll also need a flag that says if the element is anonymous or not (mContentID is used for that now, but that's going away). This would also let the editor people fix bug 155475, and who knows what we'll need flags for in the future...
*** Bug 156363 has been marked as a duplicate of this bug. ***
Attached patch Proposed fix. (obsolete) — Splinter Review
Add mFlagsOrSlots to nsGenericElement, this member is shared for storing either flags or the pointer to the nsDOMSlots, if we have slots, the flags are stored in the slots. Also sqeeze mContentID into mFlagsOrSlots (if it fits, if it doesn't, allocate slots and store the content id in the slots). Push mRangeLists and mListenerManager from the slots into hash tables (and share the hash tables with nsGenericDOMDataNode) and use a flag to say if there's a event listener manager or a range list in the hash for an element. This patch saves us 4 bytes per element, woohoo! :-)
A diff -w doesn't really make reviewing this any easier, so I didn't see a point in attaching a diff -w...
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla1.1beta
+ if (slots->IsEmpty()) { + mFlagsOrSlots = slots->mFlags | GENERIC_ELEMENT_DOESNT_HAVE_DOMSLOTS; + + delete slots; } Don't you have to add slots->mContentID to mFlagsOrSlots? nsGenericElement::GetTagName(nsAString& aTagName) { aTagName.Truncate(); - if (mNodeInfo) { - mNodeInfo->GetName(aTagName); - } + + mNodeInfo->GetName(aTagName); + return NS_OK; } you can remove the aTagName.Truncate() too now. in nsGenericElement::SetAttributeNode: + nsCOMPtr<nsIDOMNode> node(do_QueryInterface(aAttribute, &rv)), returnNode; please simply use aAttribute instead of creating the |node| variable. Same in nsGenericElement::SetAttributeNodeNS That's it for tonight, still have some stuff left to look at
Whiteboard: [HAVE FIX]
Target Milestone: mozilla1.1beta → ---
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla1.1beta
Thanks, made those changes in my local tree.
+typedef unsigned long PtrBits; IIRC we should use PRWord for bitfields that are the same size of a void* + } else { + SetFlags(aID << GENERIC_ELEMENT_CONTENT_ID_BITS_OFFSET); + } you need to unset the bits first, otherwise the new id and the old one will be or'ed together. nsGenericElement::RangeAdd(nsIDOMRange* aRange) { + PtrBits flags = GetFlags(); flags doesn't seem to be used nit: IMHO it'd be nice to have a #define for ~PtrBits(0)) >> GENERIC_ELEMENT_CONTENT_ID_BITS_OFFSET + EventListenerManagerMapEntry(const void *aKey) + : mKey(aKey), mListenerManager(nsnull) don't need to init mListenerManager since it's a nsCOMPtr with that r=sicking
PRWord is not guaranteed to be the same size as a pointer either, so I decided to stick with unsigned long (as other similar code does) and added an assertion that sizeof(PtrBits) == sizeof(void *).
Attachment #90566 - Attachment is obsolete: true
Comment on attachment 90796 [details] [diff] [review] Fix issues found by sicking Markign sicking's r=, and rpotts says sr=rpotts.
Attachment #90796 - Flags: superreview+
Attachment #90796 - Flags: review+
Whiteboard: [HAVE FIX] → [HAVE FIX, CHECKMEIN]
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
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.

Attachment

General

Created:
Updated:
Size: