WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug