Bug 131096 - Pool IOSurfaces to help with allocation cost
Summary: Pool IOSurfaces to help with allocation cost
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2014-04-02 01:41 PDT by Tim Horton
Modified: 2014-04-02 20:24 PDT (History)
7 users (show)

See Also:


Attachments
WIP (43.00 KB, patch)
2014-04-02 02:36 PDT, Tim Horton
no flags Details | Formatted Diff | Diff
patch (4.33 MB, text/plain)
2014-04-02 14:24 PDT, Tim Horton
no flags Details
patch (47.43 KB, patch)
2014-04-02 14:27 PDT, Tim Horton
simon.fraser: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2014-04-02 01:41:37 PDT
<rdar://problem/15373942>
Comment 1 Tim Horton 2014-04-02 02:36:44 PDT
Created attachment 228377 [details]
WIP
Comment 2 Tim Horton 2014-04-02 02:37:36 PDT
WIP patch, needs perf testing and probably tuning (and a changelog)
Comment 3 Tim Horton 2014-04-02 14:24:24 PDT
Created attachment 228430 [details]
patch
Comment 4 WebKit Commit Bot 2014-04-02 14:25:57 PDT
Attachment 228430 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/cg/IOSurfacePool.h:52:  The parameter name "size" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/WebCore/platform/graphics/cg/IOSurfacePool.h:52:  The parameter name "colorSpace" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 2 in 17 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 5 Tim Horton 2014-04-02 14:27:15 PDT
Created attachment 228431 [details]
patch
Comment 6 WebKit Commit Bot 2014-04-02 14:28:37 PDT
Attachment 228431 [details] did not pass style-queue:


ERROR: Source/WebCore/platform/graphics/cg/IOSurfacePool.h:52:  The parameter name "size" adds no information, so it should be removed.  [readability/parameter_name] [5]
ERROR: Source/WebCore/platform/graphics/cg/IOSurfacePool.h:52:  The parameter name "colorSpace" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 2 in 14 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 Simon Fraser (smfr) 2014-04-02 15:48:18 PDT
Comment on attachment 228431 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=228431&action=review

> Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:108
> +        showPoolStatistics();

Do you really want all these showPoolStatistics calls?

> Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:112
> +    for (auto surfaceIter = mapIter->value.begin(); surfaceIter != mapIter->value.end(); ++surfaceIter) {

auto& ? I never know.

> Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:114
> +        RefPtr<IOSurface> surface = surfaceIter->get();
> +        if (!surfaceMatchesParameters(*surface, size, colorSpace))

Do we have to pay the ref() cost by making the refptr when we don't actually use the surface?

> Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:137
> +        RefPtr<IOSurface> surface = surfaceIter->get();
> +        if (!surfaceMatchesParameters(*surface, size, colorSpace))

Ditto.

> Source/WebCore/platform/graphics/cg/IOSurfacePool.h:91
> +    void scheduleCollectionTimer();
> +    void collectionTimerFired(Timer<IOSurfacePool>&);
> +    void collectInUseSurfaces();

Is this "collect" in the garbage collection sense? Not clear from the context.
Comment 8 Tim Horton 2014-04-02 16:59:58 PDT
(In reply to comment #7)
> (From update of attachment 228431 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=228431&action=review
> 
> > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:108
> > +        showPoolStatistics();
> 
> Do you really want all these showPoolStatistics calls?

I do, they're super useful for debugging. I would add a log channel but they're useful in release too. Maybe a macro that makes the call sites disappear if logging is disabled.

> > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:112
> > +    for (auto surfaceIter = mapIter->value.begin(); surfaceIter != mapIter->value.end(); ++surfaceIter) {
> 
> auto& ? I never know.

Not with iterators I think (compiler complains).

> > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:114
> > +        RefPtr<IOSurface> surface = surfaceIter->get();
> > +        if (!surfaceMatchesParameters(*surface, size, colorSpace))
> 
> Do we have to pay the ref() cost by making the refptr when we don't actually use the surface?

No! Will fix.

> > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:137
> > +        RefPtr<IOSurface> surface = surfaceIter->get();
> > +        if (!surfaceMatchesParameters(*surface, size, colorSpace))
> 
> Ditto.
> 
> > Source/WebCore/platform/graphics/cg/IOSurfacePool.h:91
> > +    void scheduleCollectionTimer();
> > +    void collectionTimerFired(Timer<IOSurfacePool>&);
> > +    void collectInUseSurfaces();
> 
> Is this "collect" in the garbage collection sense? Not clear from the context.

I don't exactly know what to call it. It was at some point "collectInUseSurfacesAndMarkUnusedSurfacesPurgeable" but that is very long. And "collect" meant "move surfaces that aren't in-use anymore from the in-use pool to the unused pool".
Comment 9 Tim Horton 2014-04-02 17:35:15 PDT
http://trac.webkit.org/changeset/166682
Comment 10 Sam Weinig 2014-04-02 19:45:49 PDT
> > > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:112
> > > +    for (auto surfaceIter = mapIter->value.begin(); surfaceIter != mapIter->value.end(); ++surfaceIter) {
> > 
> > auto& ? I never know.
> 
> Not with iterators I think (compiler complains).

Why not:
    for (auto& surface : mapIter->value) {
    }
Comment 11 Tim Horton 2014-04-02 20:17:23 PDT
(In reply to comment #10)
> > > > Source/WebCore/platform/graphics/cg/IOSurfacePool.cpp:112
> > > > +    for (auto surfaceIter = mapIter->value.begin(); surfaceIter != mapIter->value.end(); ++surfaceIter) {
> > > 
> > > auto& ? I never know.
> > 
> > Not with iterators I think (compiler complains).
> 
> Why not:
>     for (auto& surface : mapIter->value) {
>     }

Because Deque::remove takes an iterator? Is there a good way to make this work with range-based for?
Comment 12 Simon Fraser (smfr) 2014-04-02 20:24:46 PDT
> I don't exactly know what to call it. It was at some point "collectInUseSurfacesAndMarkUnusedSurfacesPurgeable" but that is very long.

You could have put that in a comment.