Bug 136575

Summary: [CSS Grid Layout] Do not grow tracks when the growth factor is 0
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: New BugsAssignee: Sergio Villar Senin <svillar>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, darin, dino, esprehn+autocc, glenn, jfernandez, kling, kondapallykalyan, rego
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 60731, 136940    
Attachments:
Description Flags
Patch
none
Patch darin: review+

Sergio Villar Senin
Reported 2014-09-05 07:12:17 PDT
[CSS Grid Layout] Do not grow tracks when the growth factor is 0
Attachments
Patch (2.43 KB, patch)
2014-09-05 07:31 PDT, Sergio Villar Senin
no flags
Patch (4.41 KB, patch)
2014-09-15 03:11 PDT, Sergio Villar Senin
darin: review+
Sergio Villar Senin
Comment 1 2014-09-05 07:31:22 PDT
Sergio Villar Senin
Comment 2 2014-09-12 06:44:41 PDT
Ping
Darin Adler
Comment 3 2014-09-12 07:24:11 PDT
Comment on attachment 237690 [details] Patch If this really makes such a significant difference, there are a lot of other things you should consider to make this code faster. The most obvious one would be to consider if "track.m_maxBreadth - trackBreadth" is usually 0 and if so, skip the availableLogicalSpaceShare computation entirely. It seems bizarre that this would be so hot that adding the branch just to avoid some addition and subtraction operations would make a measurable difference.
Sergio Villar Senin
Comment 4 2014-09-15 02:28:54 PDT
(In reply to comment #3) > (From update of attachment 237690 [details]) > If this really makes such a significant difference, there are a lot of other things you should consider to make this code faster. The most obvious one would be to consider if "track.m_maxBreadth - trackBreadth" is usually 0 and if so, skip the availableLogicalSpaceShare computation entirely. > > It seems bizarre that this would be so hot that adding the branch just to avoid some addition and subtraction operations would make a measurable difference. That shocked me too, there seem no be no clear reason why the difference is so significant, but it was there when I tried the patch. I gave it another run today, and it seems that the difference is no longer there, I'm not getting significant improvements (+0.6% at the most) anymore so I think I'm abandoning this.
Sergio Villar Senin
Comment 5 2014-09-15 03:11:38 PDT
Sergio Villar Senin
Comment 6 2014-09-15 05:28:25 PDT
So in the end I gave it another shot and decided to implement the improvement you suggested. That resulted in a ~4% gain which was great, but then I realized that we could avoid a lot of useless work when there is no extra space to distribute. So I got a compact patch that gives us 16% of improvement (even 22% in some machines) in the auto-grid-lots-of-data.html perf test case. Obviously for real world use cases the improvement wouldn't likely be that huge but it's a good step forward IMO.
Sergio Villar Senin
Comment 7 2014-09-15 08:11:22 PDT
Comment on attachment 238111 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=238111&action=review > Source/WebCore/rendering/RenderGrid.cpp:605 > + LayoutUnit growthShare = std::min(availableLogicalSpaceShare, track.m_maxBreadth - trackBreadth); This should be obviously std::min(availableLogicalSpaceShare, trackGrowthPotential), will fix it before landing if r+'ed
Sergio Villar Senin
Comment 8 2014-09-16 01:10:32 PDT
Darin could you review the patch again please? It's finally quite different to the original one.
Sergio Villar Senin
Comment 9 2014-09-22 08:49:35 PDT
Gentle reminder...
Sergio Villar Senin
Comment 10 2014-09-23 01:37:24 PDT
Note You need to log in before you can comment on or make changes to this bug.