skia2/tests/VarAllocTest.cpp
mtklein 59dba146fe 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
2014-12-12 08:41:24 -08:00

14 lines
365 B
C++

#include "Test.h"
#include "SkVarAlloc.h"
DEF_TEST(VarAlloc, r) {
SkVarAlloc va(4/*start allocating at 16B*/);
char* p = va.alloc(128, SK_MALLOC_THROW);
sk_bzero(p, 128); // Just checking this is safe.
#ifndef SK_BUILD_FOR_ANDROID
// This method will always return 0 on Android.
REPORTER_ASSERT(r, va.approxBytesAllocated() >= 128);
#endif
}