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)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 544834
Milestone:
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.
Status: NEW → ASSIGNED
Keywords: perf
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
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.
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!!!
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.
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.
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.
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.
I will provide the space savings later today - thanks for doing the performance analysis, John.
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
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
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
Blocks: 56362
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.
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_
julien.rivaud@ens-lyon.fr, please raise such things on www-style@w.org. Bugzilla is not the right place to discuss this.
QA Contact: ian → style-system
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.