Bug 81733

Summary: Make Length Calculation functions non-inline
Product: WebKit Reporter: Joe Thomas <joethomas>
Component: CSSAssignee: Joe Thomas <joethomas>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, dglazkov, koivisto, macpherson, menard, rakuco, shanestephens, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
ProposedPatch
none
Patch-updated
webkit.review.bot: commit-queue-
Patch
koivisto: review+, webkit.review.bot: commit-queue-
Patch-BasedOn-ReviewComments none

Joe Thomas
Reported 2012-03-20 20:50:00 PDT
Currently length calculation functions in LengthFunctions.h are inline. A decent rule of thumb is to not inline a function if it is more than 10 lines long. Also it's typically not cost effective to inline functions with loops or switch statements (Reference: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Inline_Functions). Each of these functions are expected to grow by 10 more line as part of bug 27160. Also for bug 27160, in order to calculate viewport size using RenderView class, the inclusion of RenderView.h in LengthFunctions.h cause circular dependency between headers and it fails to compile, so it's better to separate the implementation of these functions.
Attachments
ProposedPatch (16.92 KB, patch)
2012-03-20 20:59 PDT, Joe Thomas
no flags
Patch-updated (18.47 KB, patch)
2012-03-20 22:15 PDT, Joe Thomas
webkit.review.bot: commit-queue-
Patch (18.52 KB, patch)
2012-03-21 07:53 PDT, Joe Thomas
koivisto: review+
webkit.review.bot: commit-queue-
Patch-BasedOn-ReviewComments (14.57 KB, patch)
2012-03-22 10:08 PDT, Joe Thomas
no flags
Joe Thomas
Comment 1 2012-03-20 20:59:43 PDT
Created attachment 132961 [details] ProposedPatch
Joe Thomas
Comment 2 2012-03-20 22:15:45 PDT
Created attachment 132971 [details] Patch-updated Resubmitting the patch as the previous patch failed to apply.
WebKit Review Bot
Comment 3 2012-03-20 23:09:22 PDT
Comment on attachment 132971 [details] Patch-updated Attachment 132971 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12035257 New failing tests: fast/dom/error-to-string-stack-overflow.html
Joe Thomas
Comment 4 2012-03-21 07:18:06 PDT
(In reply to comment #3) > (From update of attachment 132971 [details]) > Attachment 132971 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/12035257 > > New failing tests: > fast/dom/error-to-string-stack-overflow.html Looks like this test case is flaky. Bug 81740 also failed this test. I will re-submit the patch.
Joe Thomas
Comment 5 2012-03-21 07:53:16 PDT
Created attachment 133040 [details] Patch Patch resubmitting as the chromium test fails.
WebKit Review Bot
Comment 6 2012-03-21 08:47:25 PDT
Comment on attachment 133040 [details] Patch Attachment 133040 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12035532 New failing tests: fast/eventsource/eventsource-url-attribute.html
Joe Thomas
Comment 7 2012-03-21 09:07:56 PDT
(In reply to comment #6) > (From update of attachment 133040 [details]) > Attachment 133040 [details] did not pass chromium-ews (chromium-xvfb): > Output: http://queues.webkit.org/results/12035532 > > New failing tests: > fast/eventsource/eventsource-url-attribute.html Not related to my change. I think revision 111544 should fix this.
Alexey Proskuryakov
Comment 8 2012-03-21 09:41:27 PDT
Did you check svn history, why are these functions inline in the first place? Applying rules of thumb can be destructive if someone did actual research that showed the benefit of inlining these.
Antti Koivisto
Comment 9 2012-03-21 14:07:59 PDT
It is hard to say if inlining is helping or hurting here. It would be good to run some performance tests with and without the change. PerformanceTests/Layout/html5-full-render.html for example might be interesting.
Joe Thomas
Comment 10 2012-03-21 14:34:24 PDT
I checked the svn history (http://trac.webkit.org/browser/trunk/WebCore/khtml/misc/khtmllayout.h?rev=1326), and these Length calculation functions are copied from KDE project. These functions were in the same format then also (inline with swtich statement). I will do the profiling today evening as Antti suggested and update the results.
Joe Thomas
Comment 11 2012-03-21 21:46:38 PDT
I ran PerformanceTests/Parser/html5-full-render.html on Mac Snow-Leopard with and without the patch with webkit version 111625 and did not see much performance difference. r111625 - {16156.0 ms, 16106.0 ms, 16130.5 ms, 16138.5 ms, 16142.0 ms, 16099.5 ms} -- Average: 16129 ms. r111625 with patch - {16192.0 ms, 16148.0 ms, 16115.0 ms, 16120.5 ms, 16145.0 ms 16146.0 ms} -- Average: 16144 ms. Since these functions are expected to grow again with the introduction of new units in bug 27160, it might be good idea to make these functions regular.
Antti Koivisto
Comment 12 2012-03-22 05:59:39 PDT
Comment on attachment 133040 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=133040&action=review r=me, we can always roll out if the perf bots hate it. I think it should be ok though, these functions are pretty big for inlining. > Source/WebCore/ChangeLog:3 > + Make Length Calculation functions regular. Please make the title match the bug. > Source/WebCore/ChangeLog:6 > + Making the Length calculation functions regular and moving them to LengthFunctions.cpp file. Some motivation and perf testing information here would be good.
Joe Thomas
Comment 13 2012-03-22 10:08:22 PDT
Created attachment 133286 [details] Patch-BasedOn-ReviewComments
WebKit Review Bot
Comment 14 2012-03-22 11:11:12 PDT
Comment on attachment 133286 [details] Patch-BasedOn-ReviewComments Clearing flags on attachment: 133286 Committed r111733: <http://trac.webkit.org/changeset/111733>
WebKit Review Bot
Comment 15 2012-03-22 11:11:18 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.