SkRecord: increase min block to 512B, remove max.
authormtklein <mtklein@chromium.org>
Fri, 12 Dec 2014 16:41:23 +0000 (08:41 -0800)
committerCommit bot <commit-bot@chromium.org>
Fri, 12 Dec 2014 16:41:24 +0000 (08:41 -0800)
When we added the 64K allocation cap, the bots showed we took a perf hit
on some large .skps like desk_pokemonwiki.skp, despite not seeing a local
effect.  I'm still not seeing that locally, but I'd like to try removing the cap on
the bots to see what happens.  For big monolithic pictures, really packing into
memory tightly is probably not as important as it is for tiny ones.

Similarly, we're probably being too cautious about making tiny allocations.
Today we start at 16 bytes, which isn't really enough to record anything.
Even the smallest picture, say,
    save
        clipRect
        drawRect
    restore
requires ~200 bytes, so we might as well move our minimum block size up
near there.

I don't know if 16 bytes is too small to start for GrTextStrikes, so I've left the
behavior the same (though the max is still gone).

Local recording performance is neutral-to-positive:
             tabl_deviantart.skp  126us ->  129us 1.02x
                tabl_nytimes.skp  110us ->  112us 1.02x
           tabl_cuteoverload.skp  521us ->  530us 1.02x
             desk_mobilenews.skp  673us ->  682us 1.01x
             desk_chalkboard.skp  843us ->  854us 1.01x
                 desk_sfgate.skp  528us ->  535us 1.01x
            desk_silkfinance.skp 68.2us ->   69us 1.01x
                desk_youtube.skp  623us ->  629us 1.01x
                desk_blogger.skp  472us ->  475us 1.01x
     desk_jsfiddlehumperclip.skp 42.2us -> 42.5us 1.01x
                   desk_espn.skp  255us ->  256us 1.01x
                   desk_ebay.skp  174us ->  174us 1x
                desk_twitter.skp  454us ->  455us 1x
                 tabl_pravda.skp  200us ->  201us 1x
              desk_wordpress.skp  782us ->  784us 1x
               desk_samoasvg.skp  762us ->  761us 1x
                tabl_mozilla.skp 1.58ms -> 1.58ms 1x
               tabl_slashdot.skp  107us ->  107us 1x
               tabl_techmeme.skp  102us ->  102us 0.99x
            tabl_gamedeksiam.skp  729us ->  724us 0.99x
                 tabl_nofolo.skp 65.3us -> 64.7us 0.99x
            desk_gmailthread.skp  339us ->  336us 0.99x
                tabl_sahadan.skp   91us ->   90us 0.99x
           desk_yahooanswers.skp  144us ->  142us 0.99x
                   tabl_cnet.skp  143us ->  141us 0.99x
             tabl_googleblog.skp  206us ->  203us 0.99x
                    tabl_cnn.skp  160us ->  158us 0.99x
               tabl_frantzen.skp 50.5us -> 49.6us 0.98x
               desk_linkedin.skp  328us ->  323us 0.98x
                   tabl_digg.skp  790us ->  769us 0.97x
         desk_jsfiddlebigcar.skp 40.6us -> 39.5us 0.97x
                 desk_mapsvg.skp 1.57ms -> 1.52ms 0.97x
                  tabl_gmail.skp 19.4us -> 18.6us 0.96x
                   tabl_hsfi.skp 9.81us -> 9.11us 0.93x

BUG=skia:

Review URL: https://codereview.chromium.org/793033002

src/core/SkRecord.h
src/core/SkVarAlloc.cpp
src/core/SkVarAlloc.h
src/gpu/GrFontCache.cpp
tests/VarAllocTest.cpp

index a8b4256..fb08294 100644 (file)
@@ -30,7 +30,7 @@ class SkRecord : public SkNVRefCnt<SkRecord> {
         kFirstReserveCount = 64 / sizeof(void*),
     };
 public:
-    SkRecord() : fCount(0), fReserved(0) {}
+    SkRecord() : fCount(0), fReserved(0), fAlloc(8/*start block sizes at 256 bytes*/) {}
     ~SkRecord();
 
     // Returns the number of canvas commands in this SkRecord.
index 8f84b95..ba5d6f5 100644 (file)
@@ -7,11 +7,6 @@
     #include <malloc.h>
 #endif
 
-enum {
-    kMinLgSize =  4,  // The smallest block we'd ever want to allocate is 16B,
-    kMaxLgSize = 16,  // and we see no benefit allocating blocks larger than 64K.
-};
-
 struct SkVarAlloc::Block {
     Block* prev;
     char* data() { return (char*)(this + 1); }
@@ -24,10 +19,10 @@ struct SkVarAlloc::Block {
     }
 };
 
-SkVarAlloc::SkVarAlloc()
+SkVarAlloc::SkVarAlloc(size_t minLgSize)
     : fByte(NULL)
     , fRemaining(0)
-    , fLgSize(kMinLgSize)
+    , fLgSize(minLgSize)
     , fBlock(NULL) {}
 
 SkVarAlloc::~SkVarAlloc() {
@@ -42,7 +37,7 @@ SkVarAlloc::~SkVarAlloc() {
 void SkVarAlloc::makeSpace(size_t bytes, unsigned flags) {
     SkASSERT(SkIsAlignPtr(bytes));
 
-    size_t alloc = 1<<fLgSize;
+    size_t alloc = 1<<fLgSize++;
     while (alloc < bytes + sizeof(Block)) {
         alloc *= 2;
     }
@@ -50,10 +45,6 @@ void SkVarAlloc::makeSpace(size_t bytes, unsigned flags) {
     fByte = fBlock->data();
     fRemaining = alloc - sizeof(Block);
 
-    if (fLgSize < kMaxLgSize) {
-        fLgSize++;
-    }
-
 #if defined(SK_BUILD_FOR_MAC)
     SkASSERT(alloc == malloc_good_size(alloc));
 #elif defined(SK_BUILD_FOR_UNIX)
index 4031992..fb55192 100644 (file)
@@ -5,7 +5,8 @@
 
 class SkVarAlloc : SkNoncopyable {
 public:
-    SkVarAlloc();
+    // Smallest block we'll allocate is 2**N bytes.
+    explicit SkVarAlloc(size_t minLgSize);
     ~SkVarAlloc();
 
     // Returns contiguous bytes aligned at least for pointers.  You may pass SK_MALLOC_THROW, etc.
@@ -32,7 +33,7 @@ private:
 
     char* fByte;
     unsigned fRemaining;
-    unsigned fLgSize;  // This is always in the range [4, 16], so it really only needs 4 bits.
+    unsigned fLgSize;
 
     struct Block;
     Block* fBlock;
index cd1bada..3e83e6c 100644 (file)
@@ -226,7 +226,8 @@ void GrFontCache::dump() const {
     atlas and a position within that texture.
  */
 
-GrTextStrike::GrTextStrike(GrFontCache* cache, const GrFontDescKey* key) {
+GrTextStrike::GrTextStrike(GrFontCache* cache, const GrFontDescKey* key)
+    : fPool(9/*start allocations at 512 bytes*/) {
     fFontScalerKey = key;
     fFontScalerKey->ref();
 
index d6a288d..18e4214 100644 (file)
@@ -2,7 +2,7 @@
 #include "SkVarAlloc.h"
 
 DEF_TEST(VarAlloc, r) {
-    SkVarAlloc va;
+    SkVarAlloc va(4/*start allocating at 16B*/);
     char* p = va.alloc(128, SK_MALLOC_THROW);
     sk_bzero(p, 128);  // Just checking this is safe.