Closed
Bug 26429
Opened 25 years ago
Closed 17 years ago
put XUL elements on a diet
Categories
(Core :: XUL, defect, P3)
Core
XUL
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: waterson, Assigned: waterson)
References
Details
(Keywords: perf, Whiteboard: [nav+perf])
Attachments
(3 files, 4 obsolete files)
13.39 KB,
patch
|
bugs
:
review+
brendan
:
superreview+
|
Details | Diff | Splinter Review |
797 bytes,
patch
|
Details | Diff | Splinter Review | |
754 bytes,
patch
|
brendan
:
review+
brendan
:
superreview+
brendan
:
approval+
|
Details | Diff | Splinter Review |
XUL elements currently require 92 bytes per element. That's 40 bytes for 10 32-bit fields 4 bytes for the mRefCnt 38 bytes for vtable overhead. Explore: 1. packing some of the fields. 2. removing some of the fields (e.g., mDocument) 3. delegating rarely-used interfaces to an aggregate pointer that is kept in the mSlots member.
Assignee | ||
Updated•25 years ago
|
Comment 1•25 years ago
|
||
Make that 48 bytes for vtable overhead. Waterson knew that... it was just a typo.
Assignee | ||
Updated•24 years ago
|
Target Milestone: M15 → M16
Comment 2•24 years ago
|
||
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Assignee | ||
Updated•24 years ago
|
Target Milestone: M16 → Future
Comment 3•24 years ago
|
||
QueryInterface in nsXULElement seems to occur quite high in performance measurements (with jprof on Linux).
Assignee | ||
Comment 4•24 years ago
|
||
Marko: who are the big callers?
Comment 5•24 years ago
|
||
common caller seems to be SelectorMatches (I need to to a jprof again and will post it, it may have been improved recently). Two more observations: - Changing nsID::Equals to compare pointers first seems to be a slight improvement. - GetIID functions seem to follow the pattern: static const nsIID& GetIID() { static nsIID iid = NS_IEDITOR_IID; return iid;} egcs-1.1.2 is unable to inline this (I haven't managed). If I change the iid to be object static variable, the inlining is possible. Does doing this make sense? I haven't tried a newer gcc yet.
Assignee | ||
Comment 6•23 years ago
|
||
Bug 71530 removes two fields from the XUL element's slots.
Depends on: 71530
Assignee | ||
Comment 7•23 years ago
|
||
mPrototype and mSlots are mutually exclusive, and should be a |union|.
Updated•23 years ago
|
Whiteboard: [nav+perf]
Comment 8•22 years ago
|
||
Is the union of mSlots and mPrototype still a valid suggestion?
Comment 9•22 years ago
|
||
I noticed that mLineNo is always -1 for nsXULPrototypeElement so I moved it from nsXULPrototypeNode to nsXULPrototypeScript I haven't crashed yet with this patch :) It should save some memory. What do you think ?
Comment 10•22 years ago
|
||
Comment on attachment 100280 [details] [diff] [review] patch Where did the FastLoad support for script line numbers go? The XUL prototype document fastload version identifier needs to change for any incompatible change to the FastLoad file format (such as removing 32 bits of line number data from each element's serialization, including it only for script elements). /be
Attachment #100280 -
Flags: needs-work+
Comment 11•22 years ago
|
||
brendan, did you mean something like this ? -#define MFL_FILE_VERSION 3 // fix to store dependency mtimes +#define MFL_FILE_VERSION 4 // removed line numbers from elements and there is still support for script line numbers, I didn't remove that.
Comment 12•22 years ago
|
||
No, I meant change XUL_FASTLOAD_FILE_VERSION by -1 -- see http://lxr.mozilla.org/mozilla/source/content/xul/document/public/nsIXULPrototypeCache.h#136 (the macro you changed versions the XUL-independent, XPCOM-generic superstructure format of the FastLoad file, but that format didn't change in your patch). Good call on fixing this, btw -- I missed the independent mLineNo serialization and deserialization for script nodes that you left intact (I thought scripts partook of the Read32 and Write32 calls that you removed). I'm attaching my version of your patch, which fixes a mislocated memset that could crash on out-of-memory, in nsXULElement.cpp. /be
Comment 13•22 years ago
|
||
Hoping Ben will review as module owner in this case. /be
Attachment #100280 -
Attachment is obsolete: true
Comment 14•22 years ago
|
||
Thanks for help. I converted PRBools to PRPackedBools too.
Attachment #100369 -
Attachment is obsolete: true
Comment 15•22 years ago
|
||
You might even change mLineNo to a PRUint16 and pack it next to the PRPackedBools for best space efficiency. I doubt we support JS files or XUL files containing scripts that have > 64K lines; the JS engine does not. /be
Comment 16•22 years ago
|
||
new patch incorporating brendan's last suggestion
Attachment #100370 -
Attachment is obsolete: true
Comment 17•22 years ago
|
||
could I get r/sr on this ?
Comment 18•22 years ago
|
||
err, new patch coming
Comment 20•22 years ago
|
||
Comment on attachment 100387 [details] [diff] [review] fix sr=brendan@mozilla.org, this looks good to me. Ben is busy with university work for a few days, but should be back to r= this soon. If you want it sooner, maybe hyatt will do the deed. /be
Attachment #100387 -
Flags: superreview+
Comment 21•22 years ago
|
||
Comment on attachment 100387 [details] [diff] [review] fix r=ben@netscape.com
Attachment #100387 -
Flags: review+
Comment 22•22 years ago
|
||
Comment on attachment 100387 [details] [diff] [review] fix patch has been checked in
Comment 23•22 years ago
|
||
could this bug be the reason for the big perf regression in bug 170704
Comment 24•22 years ago
|
||
attaching patch that I had to check in to fix startup regression
Assignee | ||
Comment 25•22 years ago
|
||
re: comment #8, I'm not sure if it's valid anymore. When I first wrote this, lightweight XUL elements would have a prototype pointer (and no slots), and heavyweight XUL elements would have a slots pointer (and no prototype). Since then, shaver and I changed stuff so that altering an attribute's value wouldn't necessarily cause the XUL element to "fault" and become heavy. So now, it may be possible for an element to have both a prototype pointer and a slots pointer...but it's been so long since I've looked at this that I can't really remember.
Comment 26•22 years ago
|
||
> So now, it may be possible for an element to have both a prototype pointer and
> a slots pointer...
from what I saw in the code I think this is the case.
Yes, that's the case.
Comment 28•22 years ago
|
||
There was a misspelling that accidentally went in with the checkin for this patch: http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsXULElement.cpp&root=/cvsroot&subdir=mozilla/content/xul/content/src&command=DIFF_FRAMESET&rev1=1.428&rev2=1.429 nsXULProtlotypeAttribute::gNumElements should be nsXULPrototypeAttribute::gNumElements. I don't know if this affects any builds since that code is only used if XUL_PROTOTYPE_ATTRIBUTE_METERING is defined.
Comment 29•22 years ago
|
||
hmm, I'll fix it. thanks for info
Comment 30•22 years ago
|
||
Comment 31•22 years ago
|
||
Comment on attachment 102334 [details] [diff] [review] patch to fixo a typo Honor system says go ahead and check this in once the tree opens to approved 1.2beta checkins. /be
Attachment #102334 -
Flags: superreview+
Attachment #102334 -
Flags: review+
Attachment #102334 -
Flags: approval+
Comment 32•22 years ago
|
||
please get an approval from drivers@mozilla.org before checking in
Brendan already gave such an approval, right above your comment. Jan's good to go with this fix, as soon as we open for approved checkins.
Comment 34•22 years ago
|
||
then please put 'a=' (also 'r=' and 'sr=') in check in comment to avoid confusion, thanks.
Comment 35•22 years ago
|
||
sorry about that, I requested an approval along with other bugs. do I really need r/sr for such a typo ?
Comment 36•22 years ago
|
||
varga: no, you don't need r= and sr= for typo fixes like this (honor system was the phrase I used to thumbnail why you don't), but nhotta was sheriff and wanted to see r=/sr=/a=brendan@mozilla.org in your CVS checkin comment. As a nicety so the sheriff doesn't panic, this seems worth doing to me. /be
Comment 37•22 years ago
|
||
ok, thanks for the explanation. I will keep it in my mind in future.
Comment 38•18 years ago
|
||
Just FYI, nowadays XUL Element takes 44 bytes (32bit system), and bug 363067 will reduce that still 4 bytes. On 1.8 branch the size is 52 bytes.
Comment 39•17 years ago
|
||
Bug 363067 is now fixed. Making nsXULElement even smaller is hard. Marking this fixed.
Depends on: 363067
Updated•17 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•