skia2/tests/VarAllocTest.cpp

#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
}
SkVarAlloc::approxBytesAllocated() This is what I was getting at on the other CL. BUG=skia: Committed: https://skia.googlesource.com/skia/+/f27f1bcce50c8f95aea8469684a70b70c9baee09 CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Release-Trybot Review URL: https://codereview.chromium.org/730193003 2014-11-18 17:32:36 +00:00			`#include "Test.h"`
			`#include "SkVarAlloc.h"`

			`DEF_TEST(VarAlloc, r) {`
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 16:41:23 +00:00			`SkVarAlloc va(4/start allocating at 16B/);`
SkVarAlloc::approxBytesAllocated() This is what I was getting at on the other CL. BUG=skia: Committed: https://skia.googlesource.com/skia/+/f27f1bcce50c8f95aea8469684a70b70c9baee09 CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Release-Trybot Review URL: https://codereview.chromium.org/730193003 2014-11-18 17:32:36 +00:00			`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`
			`}`