Closed Bug 68821 Opened 24 years ago Closed 23 years ago

[Patch] Major performance problem rendering some w3.org pages

Categories

(Core :: Web Painting, defect, P1)

Product:
Core
Component:
Web Painting
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9

People

(Reporter: jg, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: perf, platform-parity, regression)

Attachments

(5 files)

testcase (change fixed <--> scroll)
85.23 KB, text/html
Details
:active testcase with small but noticable speed problem
1.70 KB, text/html
Details
a:link:active showing a clear speed improvement
1.71 KB, text/html
Details
Patch: restrict the application of event pseudos (no BODY or HTML)
2.52 KB, patch
Details | Diff | Splinter Review
Patch to restrict what elements are sensitive to event pseudos (makes std mode the same as quirks mode behavour)
1.53 KB, patch
Details | Diff | Splinter Review 
Go to http://w3.org/ and watch it peg your CPU at 100% usage for several seconds
longer than you'd expect. This occurs even after all data is loaded.

Next, hover mouse over normal text. No problem. Now hover over links. Notice the
CPU pegs again at 100% for several seconds and Mozilla fails to recognise it's
over a link at all until the CPU settles down - the pointer does not change
shape in this time.

Page Down also incurs major performance problems, although scrolling appears to
be reasonable.

The page http://www.w3.org/TR/css3-roadmap/ also has major performance issues.
Load it up, wait for mozilla to release the CPU, then switch desktops. Come back
again and watch Mozilla peg the CPU while re-rendering the viewport. Even
double-clicking in the urlbar to select the url takes a major amount of time. As
does hovering over our toolbar buttons.

I can say that the http://w3.org/ homepage has been suffering from this problem
for at least three weeks (guessing), I cannot say about others.
My setup:

K6-2 300Mhz, 256MB Ram, 56k modem connection. Using Debian Unstable with XF4.02.
Running Mozilla built from the tip a few hours ago.

Adding perf keyword and changing severity to Major. Nominating for mozilla0.9, 1.0.
Severity: normal → major
Keywords: mozilla0.9, mozilla1.0, perf
*** Bug 68818 has been marked as a duplicate of this bug. ***
Make sure that NT is having the same problem.
Moving the mouse from one type of area on the css3-roadmap to another area (e.g.
text to whitespace or vice versa) causes the cpu to peg for 10-13 secs.

Could this be a style resolution issue? I'm wondering if the style code is
looping through rules or something daft. It could also be causing the entire
product to lock up for the duration of the CPU pegging.

Note that with another browser window open on another site such as a bugzilla
query, it hangs both (read: all) browser windows when it pegs the cpu. This is
bad, and perhaps a threading problem (complete guess)?

Can someone test on Win32 and Mac please.

Just tested with build 2001013010-mtrunk on linux and the problem is still
there, so it occured before then.

worksforme build 2001021320 on win95. Might be linux-only.
I just did export disable_style_context_sharing = 1 and re-ran mozilla. It made
no difference, it's still a killer on those pages.

Reading the affected pages is very painful indeed - borderline usable at all.

I see this with a 2001-01-16 build also...
CCing hyatt and waterson who may be able to shed some light in this area.

Please note that the w3.org homepage is no-where near as bad as the css3-roadmap
case. They could be seperate issues.

Ian Hickson wrote:

> On Wed, 14 Feb 2001, John Morrison wrote:
> Ian Hickson wrote:
>>> Hey guys,
>>> 
>>> This page scrolls really *really* slowly:
>>> 
>>> http://www.damowmow.com/mozilla/bugs/slow/001.html
>>> 
>>> Steps to reproduce are:
>>> 
>>> 1. load page.
>>> 2. hit down a few times.
>>> 3. try to use the scroll bar.
>>> 
>>> or
>>> 
>>> 1. minimise the window.
>>> 2. do some work for a while.
>>> 3. restore the window.
>>> 
>>> Should I file a bug, or is this a dup? I'm not very up to date with the
>>> performance bugs. This seems rather bad though.
>>> 
>>> Reproduced with Netscape commercial opt builds and Mozilla debug builds
>>> from today.
>> 
>> Is this on Linux?
> 
> No, Windows 2000. jst (cc'ed) can see it too.
> 
> It's really, really bad, particularly when scrolling with the arrow keys.


Oops. Don't know why I couldn't see this at first, but then I found that firing 
in a bunch of clicks below the thumb would cause cpu to shoot to 100% and spin.

In a debug build, pulled this afternoon, when I break during one of these 
lockups, I see this as a typical stack.

FrameManager::ReResolveStyleContext(nsIPresContext * 0x03ea58b8, nsIFrame * 
0x04f69180, nsIStyleContext * 0x04e8d128, nsIContent * 0x0414d8b8, int -1, 
nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1699
FrameManager::ReResolveStyleContext(nsIPresContext * 0x03ea58b8, nsIFrame * 
0x04f690f8, nsIStyleContext * 0x04e7b558, nsIContent * 0x0403ef90, int -1, 
nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1729
FrameManager::ReResolveStyleContext(nsIPresContext * 0x03ea58b8, nsIFrame * 
0x04f64758, nsIStyleContext * 0x041f60e8, nsIContent * 0x03fd3e10, int -1, 
nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1729
FrameManager::ReResolveStyleContext(nsIPresContext * 0x03ea58b8, nsIFrame * 
0x0410f2cc, nsIStyleContext * 0x04e6d720, nsIContent * 0x00000000, int -1, 
nsIAtom * 0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1729
FrameManager::ComputeStyleChangeFor(FrameManager * const 0x03cabcd0, 
nsIPresContext * 0x03ea58b8, nsIFrame * 0x0410f2cc, int -1, nsIAtom * 
0x00000000, nsStyleChangeList & {...}, int 0, int & 0) line 1970
nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const 
0x03fdcff0, nsIPresContext * 0x03ea58b8, nsIContent * 0x03fd3e10, nsIContent * 
0x00000000) line 9569
StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x040e7da0, 
nsIPresContext * 0x03ea58b8, nsIContent * 0x03fd3e10, nsIContent * 0x00000000) 
line 1255
PresShell::ContentStatesChanged(PresShell * const 0x03c64fa0, nsIDocument * 
0x03fa4070, nsIContent * 0x03fd3e10, nsIContent * 0x00000000) line 4277 + 49 
bytes
nsDocument::ContentStatesChanged(nsDocument * const 0x03fa4070, nsIContent * 
0x03fd3e10, nsIContent * 0x00000000) line 1582
nsEventStateManager::SetContentState(nsEventStateManager * const 0x03c786f8, 
nsIContent * 0x03fd3e10, int 4) line 2723
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03c786f8, 
nsIPresContext * 0x03ea58b8, nsEvent * 0x0012f704, nsIFrame * 0x0410f2cc, 
nsEventStatus * 0x0012f5f8, nsIView * 0x03fe95f8) line 1302
PresShell::HandleEventInternal(nsEvent * 0x0012f704, nsIView * 0x03fe95f8, 
unsigned int 1, nsEventStatus * 0x0012f5f8) line 4934 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x03c64f9c, nsIView * 0x03fe95f8, 
nsGUIEvent * 0x0012f704, nsEventStatus * 0x0012f5f8, int 0, int & 1) line 4849 
+ 25 bytes
nsView::HandleEvent(nsView * const 0x03fe95f8, nsGUIEvent * 0x0012f704, 
unsigned int 8, nsEventStatus * 0x0012f5f8, int 0, int & 1) line 372
nsView::HandleEvent(nsView * const 0x03f89ed0, nsGUIEvent * 0x0012f704, 
unsigned int 8, nsEventStatus * 0x0012f5f8, int 0, int & 1) line 345
nsView::HandleEvent(nsView * const 0x03b58040, nsGUIEvent * 0x0012f704, 
unsigned int 28, nsEventStatus * 0x0012f5f8, int 1, int & 1) line 345
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x03e59fd0, nsGUIEvent * 
0x0012f704, nsEventStatus * 0x0012f5f8) line 1424
HandleEvent(nsGUIEvent * 0x0012f704) line 68
nsWindow::DispatchEvent(nsWindow * const 0x03f89f8c, nsGUIEvent * 0x0012f704, 
nsEventStatus & nsEventStatus_eIgnore) line 687 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f704) line 708
nsWindow::DispatchMouseEvent(unsigned int 322, nsPoint * 0x00000000) line 3949 
+ 21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 322, nsPoint * 0x00000000) line 
4159
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 4019
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 
4159
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 17040125, long 
* 0x0012fbc0) line 2943 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x01240700, unsigned int 512, unsigned int 0, 
long 17040125) line 923 + 27 bytes
USER32! 77e13eb0()
USER32! 77e1401a()
USER32! 77e192da()
nsAppShellService::Run(nsAppShellService * const 0x00b4e148) line 408
main1(int 1, char * * 0x003f7e38, nsISupports * 0x00000000) line 978 + 32 bytes
main(int 1, char * * 0x003f7e38) line 1270 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87


cc: pierre and attinasi
cc'ing jst as requested -- this is the performance bug I mentioned on IRC.
Keywords: nsbeta1
OS: Linux → All
Hardware: PC → All
Whiteboard: [Hixie-P1] (major performance problem)
I'm on WinNT 4, moz build 2001021404, and i'm seeing it to. I saved that css3
page to disk - still extremely slow. However, if you remove the CSS parts in the
<head>, everything runs smoothly.
Something must be really wrong here, why are we resolving huge amounts of style
when scrolling around with the arrow keys/page up/down/clicking on the scrollbar
arrows? Grabbing the scrollbar and scrolling up n' down is still nice n' fast
once it starts scrolling...

Pierre, could this be related to your style context changes?
Keywords: regression
I don't see the lockups mentioned by John Morrison but if the page at
http://www.damowmow.com/mozilla/bugs/slow/001.html is so slow it is because it 
links the stylesheet at http://www.w3.org/StyleSheets/TR/W3C-MO which contains:
    body {
      background-attachment: fixed;
    }
The problem is that a fixed background causes the frame to set the 
NS_VIEW_PUBLIC_FLAG_DONT_BITBLT on the view, which means that the view is 
entirely redrawn everytime we scroll.

In any case, we should not be so slow if the image doesn't cover the entire area 
(as it is the case on http://www.w3.org/TR/css3-roadmap/).  Reassigned to Views 
to investigate. I'm going to attach a testcase based on the page above.  Change 
the background-attachment from 'fixed' to 'scroll' and appreciate the difference.
Assignee: karnaze → kmcclusk
Component: Layout → Views
Guys this isn't just a scrolling problem - waggle your mouse over various areas of the page! Every time we switch between say text and whitespace or over a link even, we bog down for several seconds.

Scrolling with a fixed background is always going to be slow. That is secondary
to what is happening on this page. Compare it to NS6 RTM where it is fast -
something serious has regressed, and I'm guessing that it is style related given
that stack trace, or possibly a problem with how the style contexts are parented
(it looks like the FrameManager::ReResolveStyleCOntext is doing a lot of
children).

I'd like to see what element the ContentStateChanged notification is for...
Hell, I'll take this one for now.
Assignee: kmcclusk → attinasi
Mark, Hixie tried this with the background image not fixed (i.e. the image moved
around when scrolling, it wasn't tied to the top left corner of the window) and
he (and I) still saw the problem so that seems unrelated. And scrolling is not
slow on the pages if you grab the scrollbar and wiggle it up n' down, that's
fast, but if you scroll with the keyboard, it's slow, and so is mousing over the
links on the page too, as James pointed out.
Here is some interesting data about the page - nothing definitive, but I was
surprised...

This page takes up a huge amount of memory. Here are the dumps of the style,
content, and frame objects and their sizes:

*** Style ***
Frame Type           Count TotalSize MinSize MaxSize AvgSize
----------           ----- --------- ------- ------- -------
BodyFixupRule            1        20      20      20      20
BodyRule                 1        20      20      20      20
CSSDeclarationImpl     306     53092     104     496     173
CSSImportRuleImpl        3       280      90      99      93
CSSMediaRuleImpl         2       110      54      56      55
CSSNameSpaceRuleImp      3       261      76     109      87
CSSRuleProcessor         2        72      36      36      36
CSSStyleRuleImpl       522     27144      52      52      52
CSSStyleSheet            8       832     104     104     104
CSSStyleSheetInner       8       860     104     108     107
DocumentColorRule        1        32      32      32      32
HTMLCSSStyleSheet        1        32      32      32      32
HTMLMappedAttribute      1        56      56      56      56
HTMLStyleSheet           1        92      92      92      92
MappedAttrTable          1        92      92      92      92
RuleCascade              2       336     168     168     168
StyleContextData       176    128128     728     728     728
StyleContextImpl      2893    223700      60     114      77
StyleSet                 1       228     228     228     228
TableBackgroundRule      1        16      16      16      16
TableTHRule              1        16      16      16      16
nsAttrSelector         150      6692      40      96      44
nsCSSSelector          702     30918      32     150      44
*** Total ***         4787    473029

*** CONTENT ***
Frame Type           Count TotalSize MinSize MaxSize AvgSize
----------           ----- --------- ------- ------- -------
HTMLAttributesImpl     807     63268      76     108      78
__moz_comment           30      1800      60      60      60
__moz_text            1952    168379      61     834      86
a                      333     46824     136     168     140
base                     1       120     120     120     120
body                     1        56      56      56      56
caption                  5       240      48      48      48
code                   212     26288     124     124     124
dd                      91      4368      48      48      48
dfn                     32      3968     124     124     124
div                      6       744     124     124     124
dl                      37      1776      48      48      48
dt                     100      4800      48      48      48
em                      52      2496      48      48      48
h1                       1       124     124     124     124
h2                      16      2096     124     140     131
h3                      16      1984     124     124     124
h4                      21      2604     124     124     124
head                     1        48      48      48      48
hr                       3       284      44     120      94
html                     1        48      48      48      48
img                      4       608     152     152     152
li                     114      5472      48      48      48
link                     2       344     172     172     172
ol                       3       144      48      48      48
p                      120      6444      48     124      53
pre                     29      3444      48     124     118
span                   140     15316      48     156     109
strong                  33      1584      48      48      48
style                    1       136     136     136     136
sub                     28      1344      48      48      48
table                    5       660     132     132     132
tbody                    5       260      52      52      52
td                      70      3920      56      56      56
title                    1        48      48      48      48
tr                      35      1820      52      52      52
ul                      14      1280      48     124      91
*** Total ***         4322    375139

*** FRAMES ***
Frame Type           Count TotalSize MinSize MaxSize AvgSize
----------           ----- --------- ------- ------- -------
AreaFrame                1        76      76      76      76
BlockFrame             639     48564      76      76      76
BulletFrame            114      5016      44      44      44
CanvasFrame              1        56      56      56      56
HRFrame                  3       192      64      64      64
ImageFrame               2       498     232     266     249
InlineFrame            838     46928      56      56      56
LineBox:block,big      133      7980      60      60      60
LineBox:block,small    444     17760      40      40      40
LineBox:inline,smal   1343     53720      40      40      40
ScrollFrame              2       112      56      56      56
TableCaptionFrame        5       380      76      76      76
TableCellFrame          70      6720      96      96      96
TableCellMap             5       180      36      36      36
TableColFrame           10      1040     104     104     104
TableColGroupFrame       5       340      68      68      68
TableFrame               5       740     148     148     148
TableLayoutStrategy      5       120      24      24      24
TableOuterFrame          5       440      88      88      88
TableRowFrame           35      2800      80      80      80
TableRowGroupFrame       5       340      68      68      68
TextFrame             2178    132280      60      64      60
ViewportFrame            1        60      60      60      60
*** Total ***         5871    327502
Status: NEW → ASSIGNED
Can anyone help by narrowing down the date of the regression? That would sure
help...
P1 and Mozilla 0.9 set.
Priority: -- → P1
Target Milestone: --- → mozilla0.9
To prove that this is not background related, I added
   * { background: transparent ! important } 
...to the stylesheet on:
   http://www.damowmow.com/mozilla/bugs/slow/001.html
...and the problem still occurs.
Thanks Ian - Can you try narrowing down the page to a minimum testcase? I will
try as well. Also, I just _this very moment_ got a legit copy of Quantify so
I'll try profiling the simple case of hovering over a link, since that causes
100% CPU for several seconds.
Sure... after the Boston meeting, anyway. I hope that ain't too late!
Keywords: qawanted
Damn, my comments were lost somehow... OK, here they are again.

I think that the problem is in the stylesheet. I made a local copy and removed
the :active rule and the page is fantastically better (on Linux). The problem is
that in Standard Mode we allow :active to match EVERYTHING (in quirks mode we
restrict it to just a small subset of element types). I think they really want
:link:active, and that is fine too, but :active (which is really *:active) makes
style thrash on state changes, because it has to look at everything to see what
the rule should apply to (our handling ot :active is non-optimal, and maybe it
should be improved to only even consider matching the active content nodes: I'll
add that idea to bug 62895).

If I am correct about this, I cannot see how it is a regression. Has anybody
proved this? Maybe the page has changed recently?
I tried a build from Jan 9th, and it to would peak the cpu on the damowmow 
page, so this is not a recent change in the mozilla code. 
The attachment 25550 [details] demonstrates the problem in a reduced capacity. It shows
:active being used to set the element to have a yellow background. It does not
have an image for the background. Waggling the mouse over various elements on
the page shows the CPU jump about much more than expected, up to 100%.

In attachment 25550 [details], I can see (with double-buffering turned off) that we're
doing a lot of repainting while mousing around over the testcase.  If I remove
the :active rule, that repainting goes away.  I'm not sure why an :active rule
ends up causing extensive repainting.  (We probably need to look at
nsCSSFrameConstructor::ContentStateChanged...)
May not be relevant to this bug, but
http://phpwebsite.appstate.edu/content.php?menu=1302&page_id=12 scrolls unsually
slowly, also happens to be XHTML.

I wonder if there have been some changes in the EventStateManager? Maybe some
jprof data or Quantify data can show us where we are blowing our time... I'll
try to get some profiling data and report the results.
*** Bug 69368 has been marked as a duplicate of this bug. ***
I just ran Quantify and got some nasty data. The main problem I can see is that
70 calls to CSSFrameConstructor::ContentStatesChanged result in 24,000 calls to
FrameManager::ReResolveStyleContext. Now, I know style resolution is not the
fastest thing in the world, but even making super-duper fast won't fix this
problem. The StyleContext sharing code is probably making this a small bit
slower, multiplied by 3-orders of magnitude fan out in calls it seems far worse.

I am thinking more and more that we need to restrict which elements the :active,
:hover and :focus pseudo classes can apply to. This makes a huge difference
performance-wise. Remove the doctype from the w3c page to drop into Quirks mode
to see the benefits of restricting the application of theose event pseudos. CSS2
does not define which elements can be in what states, so it is really up to us
to decide. I propose that we make the (currently) Quirks-Only restriction apply
to standard mode documents as well (at the very least, we should restrict
application so the BODY and HTML elements are not applied). In CSS3 we will have
much more rational control over what elements are event sensitive...

Here is a link to the code that is used in QuirksMode to decide if an element is
event sensitive or not:
http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsCSSStyleSheet.cpp#2875

Marc, would fixing bug 68198 help? In other words, if we could detect that a 
pseudo *didn't* apply to an element before re-resolving style, would we avoid 
this cost?
Chris, I'm not sure exactly how bug 68198 applies, it seems a bit general, but
yes, if we can determine that a rule doesn't apply before we resolve style then
that is going to help (but in this case it means knowing that an element is or
is not active). I was thinking that the appropriate bug was actually bug 62895.
The problem basically is that dynamic pseudo-classes need to be handled
differently. If we have a rule for a dynamic pseudo-class like :active then we
should treat it differently, probably keeping around a list of the currently
active elements and just applying the selector matching to that short list.

Again, making *:active not apply to the BODY or HTML elements will help a lot
too, and really it does not make much sense to apply the dynamic pseudo-classes
to those elements. I'll make this change and profile it since it is really easy...
:active probably only applies to elements that can be activated, even though
CSS2 isn't all that clear.  :hover is a different story entirely.  See bug 5693
and bug 33736 and the CSS3 UI draft.

However, why are we re-resolving style for an ":active" rule when the mouse moves?
When the mouse moves, ContentStatesChanged is called (here is the top of the
call stack)

nsCSSFrameConstructor::ContentStatesChanged
StyleSetImpl::ContentStatesChanged
PresShell::ContentStatesChanged
nsDocument::ContentStatesChanged
nsEventStateManager::SetContentState
nsEventStateManager::GenerateMouseEnterExit

nsCSSFrameConstructor::ContentStatesChanged determines that there are some
state-dependent rules, and then just plows ahead and reresolves the style of the
primary frame for the content that has had its state changed. We do not
distinguish between the kind of state that changed (active, focus, hover)
anywhere except in the style resolution itself (!) so we end up just reresolving
style, in this case on the HTML element. In ReResolveStyleContextFor on the
FrameManager we resolve the style for the HTML element (which returns no impact
hint), then we resolve for all of the undisplayed content off of the HTML
element, and then finally for all of the children, which is the whole frame
tree, essentially.

One thing that comes to mind is that we can probably skip reresolving style for
the children (in some cases) if the impact of the change for the parent is NONE,
this would help this case substantially, but what are the cases where we can do
this?

Marc: Can't we optimise this so that when an element changes :pseudo state, we
only check rules that contain :pseudo, comparing which rules match before and
which rules after the change, and only if the two lists are different go on to
fully reresolve the style contexts?
Could we do that for attributes, too, and kill several performance birds with
one stone?

*** Bug 69626 has been marked as a duplicate of this bug. ***
I'm against killing birds, but we could generalize this solution. Basically, we
need to partition style rules into meaningful collections such that we can apply
them selectively. It gets complicated, I think, because selectors can contain
complicated sequences, so one rule might be both an attribute rule and a pseudo
rule, like:

  /* blue border for hovered images in anchors with hrefs */
  a[href] img:hover { border: 1px solid blue; }

so what is it, an attribute rule or a pseudo rule, or both? I need to think
about this a lot more, but any specific comments or implementation ideas would
be gladly accepted :)

For fixing this bug, I am leaning more toward the Quirk approach for now, until
we have to worry about CSS3 UI issues anyway. Granted we may need to treat
:active and :focus differently than :hover if hierarchical hover is ever
enabled, but for now I don't think that it is an issue (and hierarchical hover
is still contentious in CSS).
We do currently partition rules based off of the rightmost selector.  There are
four partitions in order of decreasing specificity.
(1) ID rules
(2) Class Rules
(3) Tag rules
(4) Universal rules

Pseudos don't affect this partition, which means that a rule like

:focus { }

will be universal

and a rule like

div > input:focus { }

will be a tag rule.

These partitions are normally quite effective, and in my profiling experience
are usually only defeated when someone makes a universal rule (e.g., *:active {}).

Milestone shift --> Moz 0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
*** Bug 71318 has been marked as a duplicate of this bug. ***
Marc,

Have applied your patch to my opt linux tree and visited the w3.org pages again.

Good: On http://www.w3.org/TR/2001/WD-css3-roadmap-20010119 prior to patching
many 'mouse-wiggling' ops hung the browser for up to 14 secs. Following the
patch, other than occassional CPU spikes lasting barely more than a sec,
everything seems fine.

Bad: On http://www.w3.org/TR/2000/WD-css3-selectors-20001005 everything seems
fine initially but if you 'mouse-wiggle' over various cells in the main table
describing the different selectors in the upper part of the document, I see the
problem come back. Several seconds of hanging can be seen switching between
hovering over various links in that table.

So we've still got some way to go on this one.

Thanks for the input James. I have no problem believing that the patch only 
solves a small fraction of the problems - it only excludes the BODY and HTML 
element from the style reresolution. The long term solution is to fix the way we 
resolve the dynamic pseudoclass rules, but for now I'll look into expanding the 
list of excluded elements - I'm guessing some table elements can be safely 
excluded as well to cover the css3 document you cited.
Blocks: 71668
Moving to mozilla0.9
Target Milestone: mozilla0.8.1 → mozilla0.9
*** Bug 72042 has been marked as a duplicate of this bug. ***
I looked at this with Hyatt for a few minutes and I have a sneaking suspicion 
this bug is, or has sometime in the recent past become linux-only. Here are the 
symptoms I'm seeing:

- Opening the XML spec (http://www.w3.org/TR/REC-xml) takes an abnormally long 
time
- Scrolling the page causes several-second freezes
- Switching workspaces back and forth once causes a freeze-up on the order of 1 
minute (but then the page does display)
- Closing the window takes several seconds (presumably while hunks of memory 
get free'd)

I see none of these symptoms on Windows, although Hyatt says he saw them 
before...

Did something get checked in that magically fixes this?
URL: http://w3.org/ → http://www.w3.org/TR/REC-xml
Still unusably slow for me on Windows (as of a couple of days ago).
Make sure to try to scroll with the arrow keys and not the mouse.
Feels the same to me. I'm trying out Hyatt's patch to bug 62895 now, it should
help this bug immensly.
I just tried this again, with no patches, just today's pull, and it is _fast_ on
Win2K. Really, no performance problem, no CPU pegging and no freezes (and yes, I
scrolled with the mouse and with the keyboard). I'm switching over to Linux to
try it there...
Holy Moly. You're right. This is WORKSFORME on Windows 2000.
Could this be Hyatt's changes to the selector matching?

How is it on Linux for you?
Whiteboard: [Hixie-P1] (major performance problem) → [Hixie-P1] (major performance problem) WORKSFORME?
Hyatt's changes to selector matching are not on the trunk, so it is not that.
Also, on Linux this still performs very very poorly.

The plot thickens... looks like it is time for jprof again.
OS: All → Linux
Hardware: All → PC
cvs tip build today on linux still has this problem. Looks like hyatt's selector
optimisation patch didn't make any difference. Very painful indeed.

*** Bug 74136 has been marked as a duplicate of this bug. ***
keywordage
Keywords: pp
This has regressed on Windows 2000 again. These pages are slow once more:
   http://www.damowmow.com/mozilla/bugs/slow/001.html
   http://www.w3.org/TR/CCPP-struct-vocab/

What on earth caused the magical speedup the other day???!!???!!!
OS: Linux → All
Cleaning up the status whiteboard - I have no idea why it got fast on Windows 
for a few days - don't you just love it!?!

I'm preparing a different patch that just makes the current QuirkMode behavour 
apply in Standard mode as well. This was discussed with Pierre and Daniel and we 
decided that thsi is the best patch for the short term. Once that is in, another 
bug will be opened to track the real solution, which is to fix the way we 
resolve style on content state changes.
Whiteboard: [Hixie-P1] (major performance problem) WORKSFORME? → [Hixie-P1] (major performance problem)
Looking for r / sr on the patch with ID=29675
 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=29675

Please read ---Comments From Marc Attinasi 2001-04-03 22:17---
Marc, I assume that this will cause something not to work right?
QA Contact: petersen → jrgm
Marc: Something caused it to reproducably work great on Windows 2000, without
any obvious problems like killing ":hover" on body. We really, really should 
find out what that is. Who is up for trying a whole bunch of nightlies to narrow
it down to a set of check-ins, and then going through those check-ins to see
which one was responsible?

If someone will do the check-in part I'll volunteer to do the nightly part...
jrgm? You up for it?
Hixie: I notice that http://www.w3.org/TR/REC-xml is mostly better right now.
Here are the symptoms I see:

  - I can scroll normally now, whereas I couldn't before. I see no slowdown
    in scrolling.
  - I still can't switch back and forth between windows without freezing up.

The stylesheet for that page (http://www.w3.org/StyleSheets/TR/W3C-REC.css)
still contains the :active rule, so something must have been checked in to
affect this... I have a hunch that hyatt intentionally or inadvertently snuck a
patch into the relevant code...
Chris, CSS2 does not specify what elements the :active, :hover and :focus pseudo
classes apply to, so it is not a correctness problem. However, ideally we would
not restrict the application of selectors like *:hover and would let it apply to
ALL element types - this proposed change simply limits the application of
selectors like that to anchors, buttons, images, inputs, selects, and textareas,
while still allowing a selector like TAG:hover to apply to all elements except
the BODY and the HTML element.

Bottom line, it is not techincally wrong, but it is also not as flexible as we
could ideally be. Note also that IE (mac and win) have much harsher restrictions
than these even.
Gotcha. r=waterson
Okay, Sherman and I got on the sweetlou wayback machine and tried out various
builds going back to 3/19 including two builds from 3/20 on win2k. I couldn't
find one that did not show the problem with peaking the cpu, most reliably by
using the down arrow key, but also by quickly dragging down the thumb, or 
clicking several times in a row below the thumb. Don't know what to say, hixie.
John: Surreal. Oh well. Thanks for looking, dude, you rock!!!
Yes, but what was it you and attinasi saw on 3/20? Why can't I see this in 
a release build from that time? 
I was using a release build IIRC. This is indeed most peculiar.
I was using a DEBUG build when I saw the speedup on Win2K. I heard on the radio 
that there was excessive solar flare activity last month, so maybe that is the 
cause ;)
Patch attached makes performance on this class of page acceptable.
Summary: Major performance problem rendering some w3.org pages → [Patch] Major performance problem rendering some w3.org pages
(of course after we check that in this bug should stay open...)
Yeah, that's not a bad hack.  I wonder what the time investment would be to fix
bug 39642 properly (teach the AttributesAffectStyle code about the presentation
attributes and turn on the reresolution filtering for HTML as well).

I'll give sr=shaver for your patch, but I'd like to know if that sort of smarter
filtering would be helpful here.  Let's discuss!

I opened bug 75559 to cover the correct solution to handle style resolution on
content state changes.

Mike, I think that the AttributeAffectsStyle re-education that you mentioned is
a different issue altogether, but certainly one we should visit. That could make
a very nice performance improvement in cases where non-stylistic attributes are
being changed on HTML elements. I opened bug 75562 on that because I could not
find one in bugzilla.

Given these two bugs, both referencing this one, I think we can safely close
this bug once the hack is committed - agreed?
ok by me. Moving my [Hixie-P1] marker to bug 75559.
Whiteboard: [Hixie-P1] (major performance problem)
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Fix applied:

cvsroot/mozilla/content/html/style/src/nsCSSStyleSheet.cpp,v
new revision: 3.158; previous revision: 3.157

The remaining issuse are coverd in other bugs now, closing as FIXED.
*** Bug 71318 has been marked as a duplicate of this bug. ***
Keywords: qawanted
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: