We're currently side-caching one blob per InlineTextBox: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/InlineTextBoxPainter.cpp?rcl=c51531ca429e54478b286186091d83a7419ce05f&l=445

This has some downsides:

a) if there's more than one blob per ITB, we cannot cache
b) we incur the storage and record-time lookup cost of a hashmap


At the time text blobs were added, caching was critical for record_time (see CT record_time_caching_disabled numbers below), but since then a couple of things happened: SlimmingPaint and the text shaping unification+cache.

Caching is still important in order to persist SkTextBlob objects across rasterization passes (the blob unique IDs are part of Ganesh's internal cache), but now we have some other options:

1) cache the text blob ref in InlineTextBox -- this is incremental, just converting from a side-cache to direct ITB blob ownership; saves the hashmap overhead.  Prolly not worth the trouble.


2) cache the text blob ref in ShapeResult -- this is an interesting twist: cache blobs per shaped word instead of per-ITB, and use blob composition to paint line boxes.  In theory it should yield a) fewer blobs (reduced memory?), b) smaller/more granular blobs (improved raster time culling?), and c) more drawTextBlob() commands (??).


3) don't retain text blobs in Blink at all - but instead rely on SlimmingPaint's display list caching (and partial inval) for blob persistence.  A quick 10k cluster telemetry run shows no surprises with this approach (setting record_time_partial_invalidation aside, different issue): caching_disabled numbers are up significantly, but normal/caching numbers are not affected (within noise levels).

https://storage.cloud.google.com/cluster-telemetry/tasks/chromium_perf_runs/fmalita-20170217190417/html/index.html

Fieldname                                       Total           Total with Patch Percentage Change Percentage Difference
record_time_caching_disabled (ms)               12251.554       18114.511        47.855%           38.615%
record_time_partial_invalidation_ms (ms)        10080.437       14614.953        44.983%           36.724%
record_time_subsequence_caching_disabled (ms)   4181.180        4194.221          0.312%            0.311%
pixels_rasterized (pixels)                      14920351836.300 14927884947.700   0.050%            0.050%
pixels_recorded (pixels)                        52238092956.500 52235819602.200  -0.004%           -0.004%
viewport_picture_size (bytes)                   2052746201.330  2052148013.330   -0.029%           -0.029%
rasterize_time (ms)                             39125.552       39041.546        -0.215%           -0.215%
record_time (ms)                                474.747         471.162          -0.755%           -0.758%
record_time_painting_disabled (ms)              7490.734        7404.198         -1.155%           -1.162%
record_time_construction_disabled (ms)          5309.852        5228.619         -1.530%           -1.542%

So #3 seems feasible, and #2 is an interesting option to explore.