[MF]form control frames are badly bloated




Layout: Form Controls
18 years ago
8 years ago


(Reporter: buster, Unassigned)


Windows NT

Firefox Tracking Flags

(Not tracked)




18 years ago
many of the form control frames are badly bloated.  with very little work, we 
could shrink these down considerably.

for example, nsGfxListControlFrame contains 10 member variables of type PRBool.  
At 4 bytes each, this is 40 bytes per instance that can easily be squeezed into 
a 2-byte bit field.  This would save us 38 bytes per instance.  If you use 
inline getter and setters on the bit field, the performance cost is negligible.

Also, 32-bit values are used for the indexes.  Do we really ever expect a list 
box to contain 2^32 elements?  Would 16 bit values be sufficient?  If so, we 
could save an addition 16 bytes per instance.

Also, it looks like mPresContext could easily be removed by simply adding the 
pres context as a parameter to methods that need it.  I think it's always 
available to the callers.  That saves another 4 bytes, plus an addref/release 
and potential source of leak.

I suggest rod and/or peter spend a day or two knocking off the easy bloat kills 
in these classes.  Peter has already done this kind of work in some layout 
classes, it might be a good use of his time with a little help from rod.

Some of the classes in the html/forms/src directory are no longer used.  Be sure 
to only focus on the classes we're going to ship with Sea Monkey.

Other things I notice:
1) nsFormFrame contains nsVoidArray mRadioGroups.  Is mRadioGroups always used, 
or only if the form really contains radio buttons?  If the latter, maybe it 
should be a pointer, to avoid extra bloat in forms without radio buttons.

2) nsFormControlFrame holds onto the pres context.  Can that be removed by 
simply passing it around in needed methods?

Comment 1

18 years ago
Yes, I have been waiting for this one, but we may be switching to XBL form 
controls in 6.1 so I haven't invested a lot effort in cleaning it up like it 
really needs (this and nsComboboxControlframe). I wouldn't nominate it for 
nsbeta3, too many changes. 

Also, if I remember correctly there are times when I need a mPresContext and it 
isn't available, but I will make sure.


18 years ago
Target Milestone: --- → Future

Comment 2

18 years ago
since the switch to XBL is definately post-6.0, and the amount of work to make 
large improvements is very low (a day at most), and very low risk (just 
switching how boolean values are stored, for example, not changing anything 
about the semantics of the variables' use), I'd suggest spending a day on this 
before FCS.  It doesn't have to be Rod, though he should own the problem.  Peter 
is a potential resource.

Bloat is a real problem in the 6.0 timeframe.  I think it's worth persuing 
low-risk, low-cost fixes.


Comment 3

18 years ago
Just want to be clear:  I don't think it's required to do everything on the list 
in this bug for 6.0.  But I think it's worth a day to do what we can, and 
changing the booleans is a very easy task.  If that's all that happened, that 
would solve 80% of the problem.

Comment 4

17 years ago
Buster, would you flag this bug when this work you're talking about is 
completed?  Thanks dude... - ckritzer

Comment 5

17 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 6

17 years ago
I wouldn't say badly bloated, but they could use a little trimming down
Severity: normal → major
Priority: P3 → P1
Target Milestone: Future → ---


17 years ago
Summary: form control frames are badly bloated → [MF]form control frames are badly bloated
Set milestone to mozilla0.9
Target Milestone: --- → mozilla0.9


17 years ago
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 8

17 years ago
QA Contact Update
QA Contact: bsharma → vladimire
Setting milestone to future. The memory savings is minimal.
Target Milestone: mozilla0.9.1 → Future


16 years ago
Priority: P1 → P3


16 years ago
QA Contact: vladimire → tpreston
Assignee: rods → nobody
QA Contact: tpreston → layout.form-controls
You need to log in before you can comment on or make changes to this bug.