| 98b8485a4cc911420e20af2670d21a5478a06264 |
|
22-Apr-2015 |
mtklein <mtklein@chromium.org> |
O(1) SkPictureUtils::ApproxBytesUsed()
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
/external/skia/src/core/SkVarAlloc.cpp
|
| 29b1afc169576cf5e708e46b74313b5666e66249 |
|
09-Apr-2015 |
mtklein <mtklein@chromium.org> |
Rearrange SkRecord with small N in mind
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
Review URL: https://codereview.chromium.org/1061783002
/external/skia/src/core/SkVarAlloc.cpp
|
| 35f55764b81390a085fb90f624082c196fbd6229 |
|
08-Apr-2015 |
mtklein <mtklein@google.com> |
Revert of Rearrange SkRecord with small N in mind (patchset #8 id:120001 of https://codereview.chromium.org/1061783002/)
Reason for revert:
https://uberchromegw.corp.google.com/i/client.skia/builders/Test-Ubuntu-GCC-GCE-CPU-AVX2-x86-Debug/builds/149/steps/dm/logs/stdio
Original issue's description:
> Rearrange SkRecord with small N in mind
>
> This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
>
> picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
>
> I don't see any significant effect on large picture recording times from our .skps.
>
> BUG=chromium:470553
>
> Committed: https://skia.googlesource.com/skia/+/e2dd9408cd711777afaa9410427fb0d761ab004a
TBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1068383003
/external/skia/src/core/SkVarAlloc.cpp
|
| e2dd9408cd711777afaa9410427fb0d761ab004a |
|
08-Apr-2015 |
mtklein <mtklein@chromium.org> |
Rearrange SkRecord with small N in mind
This rearranges the record pointers and types so they can go in a single array, then preallocates some space for them and for the SkVarAlloc.
picture_overhead_draw bench drops from ~1000ns to 500-600ns, with no effect on picture_overhead_nodraw.
I don't see any significant effect on large picture recording times from our .skps.
BUG=chromium:470553
Review URL: https://codereview.chromium.org/1061783002
/external/skia/src/core/SkVarAlloc.cpp
|
| b83205a538f420fd78220519540503616cf636cd |
|
16-Mar-2015 |
smcgruer <smcgruer@google.com> |
Fix build for UCLIBC platforms
malloc_usable_size does not exist in UCLIBC, so fall back to just
returning 0 for SkVarAlloc::heap_size().
BUG=skia:
Review URL: https://codereview.chromium.org/1006073003
/external/skia/src/core/SkVarAlloc.cpp
|
| 59dba146fe4170c4986b2494414c08be2c93d4a2 |
|
12-Dec-2014 |
mtklein <mtklein@chromium.org> |
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
/external/skia/src/core/SkVarAlloc.cpp
|
| 0bd57b2e1eb6ff824ac59a461d1a8aa24a808886 |
|
18-Nov-2014 |
mtklein <mtklein@chromium.org> |
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
/external/skia/src/core/SkVarAlloc.cpp
|
| 52b7822fa67e1d587035165258959f9600f8572d |
|
18-Nov-2014 |
mtklein <mtklein@google.com> |
Revert of SkVarAlloc::approxBytesAllocated (patchset #5 id:80001 of https://codereview.chromium.org/730193003/)
Reason for revert:
Android needs dlmalloc_usable_size().
Original issue's description:
> 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=Test-Android-Nexus5-Adreno330-Arm7-Release-Trybot
TBR=reed@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/741443002
/external/skia/src/core/SkVarAlloc.cpp
|
| f27f1bcce50c8f95aea8469684a70b70c9baee09 |
|
18-Nov-2014 |
mtklein <mtklein@chromium.org> |
SkVarAlloc::approxBytesAllocated()
This is what I was getting at on the other CL.
BUG=skia:
Review URL: https://codereview.chromium.org/730193003
/external/skia/src/core/SkVarAlloc.cpp
|
| 975ae5e4b881d4df41fd06453a650d6312127c8d |
|
13-Nov-2014 |
mtklein <mtklein@chromium.org> |
Cap SkVarAlloc's desired block at 64K.
This means we can store fLgMinSize in 4 bits (TBD).
Local perf comparison calls this harmless-to-slightly-helpful. Nothing to get
excited about, but seems to certainly not harm perf.
BUG=skia:
Review URL: https://codereview.chromium.org/722293003
/external/skia/src/core/SkVarAlloc.cpp
|
| f2950b1c4538fa638a594af6beacd3d1434eb74d |
|
13-Nov-2014 |
mtklein <mtklein@chromium.org> |
Deparameterize SkVarAlloc.
SkRecord performance is not sensitive to these values, so we can cut some
storage. This rearranges the space-remaining logic to use a count of bytes
left rather than a pointer to the end, cutting memory usage a little more.
An SkVarAlloc used to weigh 20 or 32 bytes which now becomes 16 or 24.
I think if I think about it a bit more I can trim off that Block* too,
getting us to 12 or 16 bytes.
Because we now just always grow by doubling, this CL switches from storing
fSmallest to its log base 2. This has the nice effect of never having to worry
about it overflowing, and means we can probably squeeze it down into a byte
if we want, even 6 bits.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/bc415389855888af5a1282ca4b6bee30afa3d69d
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu12-ShuttleA-GTX660-x86-Debug-Trybot
Review URL: https://codereview.chromium.org/721313002
/external/skia/src/core/SkVarAlloc.cpp
|
| dfd5f6edf83ff6b42bf38f03b9633c65d80eb6cb |
|
13-Nov-2014 |
mtklein <mtklein@google.com> |
Revert of Deparameterize SkVarAlloc. (patchset #6 id:100001 of https://codereview.chromium.org/721313002/)
Reason for revert:
Unit test failures on 32-bit machines.
test Record_Alignment: ../../tests/RecordTest.cpp:100 is_aligned(record.alloc<uint64_t>())
Original issue's description:
> Deparameterize SkVarAlloc.
>
> SkRecord performance is not sensitive to these values, so we can cut some
> storage. This rearranges the space-remaining logic to use a count of bytes
> left rather than a pointer to the end, cutting memory usage a little more.
>
> An SkVarAlloc used to weigh 20 or 32 bytes which now becomes 16 or 24.
>
> I think if I think about it a bit more I can trim off that Block* too,
> getting us to 12 or 16 bytes.
>
> Because we now just always grow by doubling, this CL switches from storing
> fSmallest to its log base 2. This has the nice effect of never having to worry
> about it overflowing, and means we can probably squeeze it down into a byte
> if we want, even 6 bits.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/bc415389855888af5a1282ca4b6bee30afa3d69d
TBR=reed@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/718203006
/external/skia/src/core/SkVarAlloc.cpp
|
| bc415389855888af5a1282ca4b6bee30afa3d69d |
|
13-Nov-2014 |
mtklein <mtklein@chromium.org> |
Deparameterize SkVarAlloc.
SkRecord performance is not sensitive to these values, so we can cut some
storage. This rearranges the space-remaining logic to use a count of bytes
left rather than a pointer to the end, cutting memory usage a little more.
An SkVarAlloc used to weigh 20 or 32 bytes which now becomes 16 or 24.
I think if I think about it a bit more I can trim off that Block* too,
getting us to 12 or 16 bytes.
Because we now just always grow by doubling, this CL switches from storing
fSmallest to its log base 2. This has the nice effect of never having to worry
about it overflowing, and means we can probably squeeze it down into a byte
if we want, even 6 bits.
BUG=skia:
Review URL: https://codereview.chromium.org/721313002
/external/skia/src/core/SkVarAlloc.cpp
|
| 8113dd13692bc2e1fe804141d04b2cc5f03a55be |
|
13-Nov-2014 |
mtklein <mtklein@chromium.org> |
SkVarAlloc
Like SkChunkAlloc, but
- does its allocation with better sympathy for malloc granularity;
- the fast path inlines entirely;
- smaller per-block overhead;
- smaller per-SkVarAlloc overhead;
- growth parameters are a little more tunable.
Its main downside is less flexibility; it supports fewer methods than SkChunkAlloc.
These current parameters bring the first allocation down from 4K to 1K,
without affecting recording time on my desktop. skiaperf.com will tell the
whole story.
BUG=skia:
Review URL: https://codereview.chromium.org/674263002
/external/skia/src/core/SkVarAlloc.cpp
|