Closed
Bug 19459
Opened 25 years ago
Closed 23 years ago
Bloat in generated code
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
People
(Reporter: daniel, Assigned: daniel)
References
()
Details
(Keywords: dom0, Whiteboard: [BR])
Attachments
(2 files)
(Probably not the right component?)
The classes that define the DOM classes for JavaScript in /dom/src/ seem highly
ineffecient to me. The methods defined there contain case statements that is a
repetition of the following code (from GetProperty).
case HTMLTEXTAREAELEMENT_DISABLED:
{
PRBool ok = PR_FALSE;
secMan->CheckScriptAccess(scriptCX, obj,
NS_DOM_PROP_HTMLTEXTAREAELEMENT_DISABLED, PR_FALSE, &ok);
if (!ok) {
return nsJSUtils::nsReportError(cx, NS_ERROR_DOM_SECURITY_ERR);
}
PRBool prop;
nsresult result = NS_OK;
result = a->GetDisabled(&prop);
if (NS_SUCCEEDED(result)) {
*vp = BOOLEAN_TO_JSVAL(prop);
}
else {
return nsJSUtils::nsReportError(cx, result);
}
break;
}
I think that everything but the "result = a->GetDisabled(&prop)" could be moved
to outside of the case statement
Did a quick search and there appear to be about 1200 of these code blocks across
100 files. Assuming the code savings is 50 bytes per case label, the resulting
binary could by reduced in size by over 50K.
These files are generated, I couldn't find what generates them (is that code
available?). Point me to the generating code and I'll try to see how much space
is actually saved by being a little more intelligent.
Assignee | ||
Comment 1•25 years ago
|
||
Assignee | ||
Comment 2•25 years ago
|
||
> little more intelligent.
Err, sorry. I hope that sounds OK, I mean something like "trying to be more
space efficent" or something. I very much appreciate all the work that you guys
do in the open.
Looked at this again and it appears to be more complex than I first thought I
may have (a start of) an implementation that reduces code size.
Attached a file that contains some generic code for a function that can be
re-used for *getting* DOM properties. Since I don't fully understand the build
system, I put all code into nsJSHTMLButtonElement.cpp as an example. The code
compiles but I did not test if it actually works.
The implementation uses a lookup table that lists for each property: the type,
security id and pointers to getter and setter methods. The generic property
getter just accepts a pointer to this table and does its magic based on the
index of the property.
I could not find an example for a property *setter* that accepts a DOM type so
I'm not sure what information is needed for that. It might be fairly complex and
require an IID added in the lookup table.
Assignee | ||
Updated•25 years ago
|
Assignee: vidur → __UNKNOWN__
Assignee | ||
Comment 3•25 years ago
|
||
Sorry for using bugzilla as a personal scratchpad but I found the answer to most
of the questions in this bug. I changed the code generation to generate calls
into a single generic function for property getters. This saved 70K in the
optimized build of jsdom.dll (out of 370K). If I can find the time during next
week, I'll try to do the same thing for setters (I expect another 70K savings).
Assigned this to myself. Please stop me if I overlooked something important
(e.g. member pointers don't work XP).
Assignee | ||
Comment 4•25 years ago
|
||
Vidur,
People on #mozilla suggested I contact you about this one. If you have the time,
could you maybe take a look at this bug and see if I'm ovf=erlooking something
in this?
Updated•25 years ago
|
Assignee: __UNKNOWN__ → zee
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•25 years ago
|
||
I'll abondon this for the time being, out of time, leaving on a 4 week vacation
and jband seems to be doing a dom xpconnect overhaul for m13. Please close at
next cleanup or do something with the attached files.
Basic idea:
- Generate lookup tables for all properties (using member pointers)
- Use generic property/get set routines from the lookup tables
Saves about 90K on jsdom.dll for a release build on win32. It seems to work
(browser still starts), don't remember if all testcases work.
Note on the attachment:
- changed tools/JSStubGen.*
- added src/base/nsDOMJSUtils.*
did not include changed Makefiles.
Assignee | ||
Comment 6•25 years ago
|
||
Comment 7•25 years ago
|
||
Sorry this fell off my list. You're right - there's potential for bloat
reduction in the generated code. I'll check out your suggestions over the next
couple of weeks to see what we might be able to do for M13. Thanks!
Comment 8•24 years ago
|
||
zee@northrock.bm, are you still around? Vidur, do you want to take this if
not, or should we lcose this up?
Whiteboard: [BR]
Assignee | ||
Comment 9•24 years ago
|
||
Yeah. I'm still around but I currently don't have the time to contribute. If I
remember correctly, the basic story is that this bug describes some potential
for saving space in the js <-> dom bridge.
The best space saving is ofcourse getting rid of the entire bridge and just use
xpconnect. I believe bug 28833 describes what needs to be done. Maybe this bug
should be marked a duplicate of bug 28833?
Assignee | ||
Comment 10•23 years ago
|
||
Completely irrelevant right now since the JS<->DOM thing (forgot the name,
xpconnect maybe?) has landed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•