Bug 104366

Summary: Make order iterator member stack allocated in RenderFlexibleBox
Product: WebKit Reporter: Carlos Garcia Campos <cgarcia>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, dbarton, eric, kling, ojan.autocc, tony, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
ojan: review-, buildbot: commit-queue-
Updated patch
tony: review-
Updated patch
none
Updated patch to apply on current git master tony: review+

Carlos Garcia Campos
Reported 2012-12-07 05:48:55 PST
We avoid heap allocations during layout.
Attachments
Patch (25.30 KB, patch)
2012-12-07 05:57 PST, Carlos Garcia Campos
ojan: review-
buildbot: commit-queue-
Updated patch (17.95 KB, patch)
2012-12-18 05:22 PST, Carlos Garcia Campos
tony: review-
Updated patch (16.50 KB, patch)
2012-12-19 00:39 PST, Carlos Garcia Campos
no flags
Updated patch to apply on current git master (16.44 KB, patch)
2012-12-19 01:56 PST, Carlos Garcia Campos
tony: review+
Carlos Garcia Campos
Comment 1 2012-12-07 05:57:20 PST
Build Bot
Comment 2 2012-12-07 06:11:52 PST
Alexey Proskuryakov
Comment 3 2012-12-07 10:32:08 PST
> We avoid heap allocations during layout. I'm a layout expert, but this is the first time I hear about this rule. Can you please elaborate? Will this make RenderFlexibleBox much larger in some cases, or does m_orderIterator always get created eventually anyway?
Alexey Proskuryakov
Comment 4 2012-12-07 10:32:30 PST
> I'm a layout expert, I'm NOT a layout expert :)
Andreas Kling
Comment 5 2012-12-07 10:37:02 PST
What benchmark (or web page) are you targeting? How big of an improvement is this?
Eric Seidel (no email)
Comment 6 2012-12-07 10:54:02 PST
(In reply to comment #3) > > We avoid heap allocations during layout. > > I'm a layout expert, but this is the first time I hear about this rule. Can you please elaborate? We do lots of heap allocations during layout :-) I haven't read the patch yet. But that rule as stated is overbroad. :-)
Tony Chang
Comment 7 2012-12-07 12:13:00 PST
I don't think Carlos is saying that avoiding heap allocations during layout is a rule. He's just saying for this code, we'll avoid a heap allocation since we always create this object. He is simply describing the change.
Ojan Vafai
Comment 8 2012-12-07 12:18:17 PST
Comment on attachment 178209 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=178209&action=review > Source/WebCore/ChangeLog:14 > + (WebCore::RenderFlexibleBox::baselinePosition): Make it non const > + because the order iterator is modified. This doesn't work because now it's not actually overriding the parent class's virtual baselinePosition method. constness has to match. I'm not what you should do instead. :(
Tony Chang
Comment 9 2012-12-07 12:21:09 PST
(In reply to comment #8) > (From update of attachment 178209 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=178209&action=review > > > Source/WebCore/ChangeLog:14 > > + (WebCore::RenderFlexibleBox::baselinePosition): Make it non const > > + because the order iterator is modified. > > This doesn't work because now it's not actually overriding the parent class's virtual baselinePosition method. constness has to match. I'm not what you should do instead. :( I would probably make m_orderIterator mutable.
Carlos Garcia Campos
Comment 10 2012-12-08 04:55:10 PST
(In reply to comment #7) > I don't think Carlos is saying that avoiding heap allocations during layout is a rule. He's just saying for this code, we'll avoid a heap allocation since we always create this object. He is simply describing the change. Yes, exactly, the iterator was not a member at first, then it became a member and Tony suggested that maybe we could make it stack allocated, which I think makes sense, so I wrote the patch. This doesn't try to fix a performance issue in the layout algorithm.
Carlos Garcia Campos
Comment 11 2012-12-08 04:55:45 PST
(In reply to comment #8) > (From update of attachment 178209 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=178209&action=review > > > Source/WebCore/ChangeLog:14 > > + (WebCore::RenderFlexibleBox::baselinePosition): Make it non const > > + because the order iterator is modified. > > This doesn't work because now it's not actually overriding the parent class's virtual baselinePosition method. constness has to match. I'm not what you should do instead. :( Yes, I noticed it when I saw the windows build failed :-(
Carlos Garcia Campos
Comment 12 2012-12-18 05:22:39 PST
Created attachment 179926 [details] Updated patch Make the iterator mutable as suggested by Tony.
Tony Chang
Comment 13 2012-12-18 11:09:38 PST
Comment on attachment 179926 [details] Updated patch View in context: https://bugs.webkit.org/attachment.cgi?id=179926&action=review > Source/WebCore/ChangeLog:8 > + It avoids heap allocations during the layout. Nit: I would say, "It avoids a heap allocation during layout." > Source/WebCore/rendering/RenderFlexibleBox.h:92 > + void setOrderValues(const OrderHashSet& orderValues) > + { > + reset(); Can we move this method definition into the .cpp file? That would also let you keep OrderHashTraits in the .cpp file. > Source/WebCore/rendering/RenderFlexibleBox.h:107 > + RenderBox* next() > + { > + do { Can we move this method definition into the .cpp file? > Source/WebCore/rendering/RenderFlexibleBox.h:133 > + private: > + RenderFlexibleBox* m_flexibleBox; Maybe add WTF_MAKE_NONCOPYABLE(OrderIterator) to avoid accidental copies?
Carlos Garcia Campos
Comment 14 2012-12-19 00:39:16 PST
Created attachment 180110 [details] Updated patch Moved the implementation of the OrderIterator class to the cpp file and made it non copyable.
Carlos Garcia Campos
Comment 15 2012-12-19 01:56:59 PST
Created attachment 180121 [details] Updated patch to apply on current git master
Tony Chang
Comment 16 2012-12-19 10:46:57 PST
Comment on attachment 180121 [details] Updated patch to apply on current git master Thanks!
Carlos Garcia Campos
Comment 17 2012-12-20 01:19:23 PST
Note You need to log in before you can comment on or make changes to this bug.