Closed
Bug 62892
Opened 24 years ago
Closed 13 years ago
html.css needs optimization for the list selector rules
Categories
(Core :: CSS Parsing and Computation, defect, P3)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
DUPLICATE
of bug 544834
Future
People
(Reporter: attinasi, Assigned: dbaron)
References
(Depends on 1 open bug)
Details
(Keywords: perf)
The rules for lists are large and could potentially be optimized or moved to
code to reduce their impact on footprint and the speed of style resolution.
For example:
/* nested lists have no top/bottom margins */
ul ul, ul ol, ul dir, ul menu, ul dl
ol ul, ol ol, ol dir, ol menu, ol dl
dir ul, dir ol, dir dir, dir menu, dir dl
menu ul, menu ol, menu dir, menu menu, menu dl
dl ul, dl ol, dl dir, dl menu, dl dl {
margin-top: 0;
margin-bottom: 0;
}
/* 2 deep unordered lists use a circle */
ol ul, ul ul, menu ul, dir ul,
ol menu, ul menu, menu menu, dir menu,
ol dir, ul dir, menu dir, dir dir {
list-style-type: circle;
}
/* 3 deep (or more) unordered lists use a square */
ol ol ul, ol ul ul, ol menu ul, ol dir ul,
ol ol menu, ol ul menu, ol menu menu, ol dir menu,
ol ol dir, ol ul dir, ol menu dir, ol dir dir,
ul ol ul, ul ul ul, ul menu ul, ul dir ul,
ul ol menu, ul ul menu, ul menu menu, ul dir menu,
ul ol dir, ul ul dir, ul menu dir, ul dir dir,
menu ol ul, menu ul ul, menu menu ul, menu dir ul,
menu ol menu, menu ul menu, menu menu menu, menu dir menu,
menu ol dir, menu ul dir, menu menu dir, menu dir dir,
dir ol ul, dir ul ul, dir menu ul, dir dir ul,
dir ol menu, dir ul menu, dir menu menu, dir dir menu,
dir ol dir, dir ul dir, dir menu dir, dir dir dir {
list-style-type: square;
}
These rules take up a lot of space in memory, and represent lots of time in
resolving style, and they are very stable. Moving them to code could be a space
and speed benefit.
Comment 1•24 years ago
|
||
Netscape's standard compliance QA team reorganised itself once again, so taking
remaining non-tables style bugs. Sorry about the spam. I tried to get this done
directly at the database level, but apparently that is "not easy because of the
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Reporter | ||
Comment 2•24 years ago
|
||
Hmm. Really, we should remove the rules and then measure the difference in space
and performance to see if this is really worth it. If the difference is not
measurable then it is probably not a good idea because there will be some work
involved in the C++ code to set the margins and bullets, however if the impact
is significant then we should proceed to make the change.
Comment 3•24 years ago
|
||
John: You're the performance guy! :-)
Could you try a couple of your usual layout performance tests, one as normal
and one with the rules mentioned in the initial description of this bug removed?
We would like to know if they are really slowing us down or not. Cheers!!!
Assignee | ||
Comment 4•24 years ago
|
||
Perhaps performance could be improved if we changed them to use child selectors,
e.g., replace "ul ul" with "ul > li > ul". That would change the meaning, but
which did NS4 do (and what do IE and Opera do)? We could also drop support for
the bullet-changing based on nesting for dir and menu, since I don't think many
people use them anymore.
Comment 5•24 years ago
|
||
We can definitely drop the menu and dir rules without losing much. Maybe we
should make the default bullets for menu and dir be the same as the second and
third nesting levels respectively, so that in the unlikely case that someone
does use them, we have _some_ differentiation.
We could even drop the 'ol' rules, since they already use numbers and not
bullets, so we don't need to do anything special for them.
We can't use child combinators, though:
<ul>
<li>
<div>
<ul>
<li>item</li>
</ul>
</div>
</li>
</ul>
...for instance. Probably even more common is having <table>s half way through
that mess.
Comment 6•24 years ago
|
||
Well, I thought that this might make some difference (although perhaps not
enough to matter), but ...
I ran as hixie suggested: one run as normal (2001021604 win98), and then again
after deleting the rules noted above from ./res/html.css. I also swapped out
one of the regular pages for a 200K html document with nothing but UL and LI
nested five deep.
For the test as a whole there is no significant difference in page loading time
as measured by this test. It did show a ~10% speedup for the "special" page,
so the effect can be observed on a degenerate example. But the use of UL/OL/LI
is not very common (only 6 of my 40 test pages have a UL, and there are a
total of 190 LI in the 40 pages [some people use LI standalone]).
I note that my test pages are skewed towards "top100" home pages, but even a
"real" document-type page, an earlier version of DOM L2 Core, doesn't show an
appreciable gain in loading time.
However, the space question remains open, and if that were significant then
it might justify the coding time. And the other suggestions to simplify support
for DIR, MENU and OL maybe should be done in any case.
Comment 7•24 years ago
|
||
I should note that there is no measurable speed effect at this time, since
loading time is dominated by other things (e.g., cache performance, some imglib
stuff, other factors not yet identified). However, if/when these are improved,
it may be the case that there will be a measureable gain. We can test again
later.
Reporter | ||
Comment 8•24 years ago
|
||
I will provide the space savings later today - thanks for doing the performance
analysis, John.
Reporter | ||
Comment 9•24 years ago
|
||
Here is the memory breakdown: loading about:blank in Viewer (which has only
rules from the ua.css) we go from 140.4K to 128.9K in the style system - pretty
impressive! I think that this is probably worthwhile based on the ~12K memory
savings, assuming it is pretty straightforward to translate these rules into code.
With rules:
Frame Type Count TotalSize MinSize MaxSize AvgSize
---------- ----- --------- ------- ------- -------
BodyFixupRule 1 20 20 20 20
BodyRule 1 20 20 20 20
CSSDeclarationImpl 300 51408 104 496 171
CSSImportRuleImpl 3 280 90 99 93
CSSNameSpaceRuleImp 3 261 76 109 87
CSSRuleProcessor 1 36 36 36 36
CSSStyleRuleImpl 534 27768 52 52 52
CSSStyleSheet 5 520 104 104 104
CSSStyleSheetInner 5 540 108 108 108
DocumentColorRule 1 32 32 32 32
HTMLCSSStyleSheet 1 32 32 32 32
HTMLStyleSheet 1 92 92 92 92
MappedAttrTable 1 44 44 44 44
RuleCascade 1 168 168 168 168
StyleContextData 24 17472 728 728 728
StyleContextImpl 24 1602 60 110 66
StyleSet 1 228 228 228 228
TableBackgroundRule 1 16 16 16 16
TableTHRule 1 16 16 16 16
nsAttrSelector 168 7486 40 96 44
nsCSSSelector 756 32396 32 150 42
*** Total *** 1833 140437
Without Rules:
Frame Type Count TotalSize MinSize MaxSize AvgSize
---------- ----- --------- ------- ------- -------
BodyFixupRule 1 20 20 20 20
BodyRule 1 20 20 20 20
CSSDeclarationImpl 297 51060 104 496 171
CSSImportRuleImpl 3 280 90 99 93
CSSNameSpaceRuleImp 3 261 76 109 87
CSSRuleProcessor 1 36 36 36 36
CSSStyleRuleImpl 453 23556 52 52 52
CSSStyleSheet 5 520 104 104 104
CSSStyleSheetInner 5 540 108 108 108
DocumentColorRule 1 32 32 32 32
HTMLCSSStyleSheet 1 32 32 32 32
HTMLStyleSheet 1 92 92 92 92
MappedAttrTable 1 44 44 44 44
RuleCascade 1 168 168 168 168
StyleContextData 24 17472 728 728 728
StyleContextImpl 24 1602 60 110 66
StyleSet 1 228 228 228 228
TableBackgroundRule 1 16 16 16 16
TableTHRule 1 16 16 16 16
nsAttrSelector 168 7486 40 96 44
nsCSSSelector 538 25420 32 150 47
*** Total *** 1531 128901
Reporter | ||
Comment 10•24 years ago
|
||
Moving out to Mozilla 1.1 since the performance and footprint benefits are not
great (but worthwhile in the long term)
Target Milestone: --- → mozilla1.1
Assignee | ||
Comment 11•23 years ago
|
||
Taking those of attinasi's style system bugs that are really style system bugs
and still look valid.
Assignee: attinasi → dbaron
Status: ASSIGNED → NEW
Target Milestone: mozilla1.1alpha → Future
Comment 12•21 years ago
|
||
I was wondering, do we still need all the rules for the MENU and DIR elements?
There are more things we don't support that are deprecated. It would save quite
a few bytes if we dropped support for them and I don't think there are large
sites that rely on those.
Comment 13•20 years ago
|
||
As a site programmer, I really think that CSS should have a way to "nest rules",
to for example simplify rules like
#ident p.t1 em.t2:first-child a, #ident p.t1 em.t2:first-child span
{
content of rules
}
into
#ident p.t1 em.t2:firstchild
{{
a, span {rules;}
}}
for example.
This is a completely different question, but that would significantly reduce the
complexity of some CSS sheets, and speed up the whole thing, I think.
In this case, it would be rather efficient to have a mean to factorize.
_FrnchFrgg_
Comment 14•20 years ago
|
||
julien.rivaud@ens-lyon.fr, please raise such things on www-style@w.org. Bugzilla
is not the right place to discuss this.
Assignee | ||
Comment 15•19 years ago
|
||
We should really fix this using the proposals in
http://lists.w3.org/Archives/Public/www-style/1999May/0067
http://lists.w3.org/Archives/Public/www-style/1999Jun/0026
which will hopefully be added to css3-values.
Assignee | ||
Updated•18 years ago
|
QA Contact: ian → style-system
Assignee | ||
Comment 16•13 years ago
|
||
The performance issues were substantially improved by bug 544834, https://hg.mozilla.org/mozilla-central/rev/8e552e1afa49
The issue of cycling between types is bug 119753.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•