New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 662245 link

Starred by 0 users

Issue metadata

Status: Fixed
Owner:
Last visit 15 days ago
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Untouched allocations in SkGlyphCache::findImage()

Project Member Reported by dskiba@chromium.org, Nov 4 2016

Issue description

I ran an experiment to find out places where memory is allocated, but not touched (not read / written): https://groups.google.com/a/chromium.org/forum/#!topic/project-trim/1OfAa01uOa8

I found that SkGlyphCache::findImage() is responsible for 287 KiB of untouched bytes (out of 1.5 MiB).

There is TODO in SkGlyphCache::findImage() about resizing image buffer, which looks like what's happening. How hard it'll be to actually do that?
 
BTW, the distribution of unused sizes looks like this:

[% unused]  [total unused size]
    <10%         11.6 KiB
    20%          46.7 KiB
    30%          9.6 KiB
    40%          25.7 KiB
    50%          13.6 KiB
    60%          14.8 KiB
    70%          69.8 KiB
    90%          78.5 KiB

I.e. 78.5 KiB came from buffers that were >=90% unused.

Comment 2 by hcm@chromium.org, Nov 7 2016

Cc: bunge...@chromium.org
Owner: herb@chromium.org
To Herb and/or Ben who play in this space...
I'm currently working on that TODO, but I doubt it will make any difference. For efficiency the images are backed by a slab allocator so it is quite likely that there sill be a great deal of unused data at the end of the slabs at any given point. Your distribution of unused percentages is about what I would expect.
I see. But since we want to shrink most recent allocation, perhaps SkChunkAlloc could introduce 'shrink(N)' method to shrink last allocation by N bytes? That way images should end up tightly packed.
Actually, disregard that, I see that SkChunkAlloc basically allocates one block per image if image is sufficiently large. Shrinking won't help much.
Status: Assigned (was: Untriaged)

Comment 7 by dskiba@chromium.org, Jan 23 2017

Labels: -Performance-Memory-Q4 Performance-Memory-Q1
I can see that as of https://skia-review.googlesource.com/c/7112/ SkGlyphCache uses SkArenaAlloc. I'll redo my experiment to see how it helped.
Ping! This bug is assigned and has an owner, but hasn't been updated in over 180 days. Is this still something we want to do?

Comment 9 by hcm@chromium.org, Aug 3 2017

Cc: herb@chromium.org
Owner: dskiba@chromium.org
I suppose this is to dskiba@ if they have time to redo testing with the latest code.
Status: Fixed (was: Assigned)
Measurement code is hopelessly obsolete, so I can't redo the measurements. Optimistically marking as fixed.

Sign in to add a comment