RESOLVED FIXED Bug 43540
residual-style-hang times out on Gtk
https://bugs.webkit.org/show_bug.cgi?id=43540
Summary residual-style-hang times out on Gtk
Adam Barth
Reported 2010-08-05 00:09:22 PDT
This test is a stress test of a particular algorithm inside the tree builder. It's unclear whether this test times out because the bot is slow or whether we need to make a change to the code here. Hopefully someone with access to a Gtk machine can look at what's causing the hang and let us know.
Attachments
Profile of the test (692.49 KB, image/svg+xml)
2010-08-05 01:54 PDT, Alejandro G. Castro
no flags
Alejandro G. Castro
Comment 1 2010-08-05 01:09:37 PDT
(In reply to comment #0) > This test is a stress test of a particular algorithm inside the tree builder. It's unclear whether this test times out because the bot is slow or whether we need to make a change to the code here. Hopefully someone with access to a Gtk machine can look at what's causing the hang and let us know. I've tested it in the bots and it seems the problem is slowness, because it never hangs but it takes a lot of time to finish. Is there any specific test that I could do to check if the parser is doing something wrong?
Adam Barth
Comment 2 2010-08-05 01:31:21 PDT
residual-style-dom.html shows the DOM that gets produced when we hit the residual style limit. That test is passing on Gtk, so I think the parser is doing the right thing. The question is if there's some reason its slower on Gtk (or if it's just the bot's hardware).
Alejandro G. Castro
Comment 3 2010-08-05 01:54:04 PDT
Created attachment 63564 [details] Profile of the test This is not a profile in the bot, it is a profile in my machine which is faster but I guess it could help checking if there is something not expected. If we information in the profile is ok, maybe we could increase the time we use to detect a hang a little bit, the bot machine is not very fast.
Adam Barth
Comment 4 2010-08-05 02:25:13 PDT
I found that chart a bit hard to read, but I think it's saying that we're spending a ton of time inside callTheAdoptionAgency, which is correct. Another option is to reduce the depth of the test case. I suspect a depth of 100 would be a sufficiently pathological test case.
Alejandro G. Castro
Comment 5 2010-08-05 03:45:37 PDT
(In reply to comment #4) > I found that chart a bit hard to read, but I think it's saying that we're spending a ton of time inside callTheAdoptionAgency, which is correct. Another option is to reduce the depth of the test case. I suspect a depth of 100 would be a sufficiently pathological test case. Yep, I would say basically it spends 82.82% of the time in callTheAdoptionAgency, divided this way: - WebCore::ContainerNode::appendChild 40.74% - WebCore::Element::attach 36.54% - WebCore::HTMLTreeBuilder::reparentChildren 5.21% But must of this calls end up in WebCore::Node::createRendererIfNeeded one way or another, where 71.28% of the time is spent, and gettig the style is more than half of the time creating the renderer (WebCore::CSSStyleSelector::styleForElement)
James Robinson
Comment 6 2010-08-08 13:03:19 PDT
I believe that http://trac.webkit.org/changeset/64954 fixed this. If it starts timing out again, please reopen.
Note You need to log in before you can comment on or make changes to this bug.