SkRecord: increase min block to 512B, remove max.

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
This commit is contained in:
mtklein 2014-12-12 08:41:23 -08:00 committed by Commit bot
parent e832b958e0
commit 59dba146fe
5 changed files with 10 additions and 17 deletions

View 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.

View 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)

View 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;

View 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();

View 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.