678258 - More image decoding telemetry

Status: RESOLVED FIXED

(Core :: Graphics: ImageLib, defect)

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Record the time from starting a decode on draw and actually finishing.

In early testing this had some interesting values: on the order of 400ms. I have no idea why it's so high.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Record the number of chunks that we decode per trip through the event loop.

This will be useful for tuning chunk size.

Comment 3

[Justin Lebar (not reading bugmail)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)
> In early testing this had some interesting values: on the order of 400ms. I
> have no idea why it's so high.

Bug 666352 comment 33 through 35 might be helpful.  The FlushInvalidations call may also be expensive.

Comment 4

[Justin Lebar (not reading bugmail)]

Comment on attachment 552453 [details] [diff] [review]
Record the number of chunks that we decode per trip through the event loop.

> + HISTOGRAM(IMAGE_DECODE_CHUNKS, 1,  500, 50, EXPONENTIAL, "Number of chunks per decode attempt")

It seems a little weird to divide the range 1-500 into 50 exponentially-spaced buckets -- can you check that the buckets generated here are reasonable?

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(In reply to Justin Lebar [:jlebar] (out 8/12 - 8/21) from comment #4)
> Comment on attachment 552453 [details] [diff] [review]
> Record the number of chunks that we decode per trip through the event loop.
> 
> > + HISTOGRAM(IMAGE_DECODE_CHUNKS, 1,  500, 50, EXPONENTIAL, "Number of chunks per decode attempt")
> 
> It seems a little weird to divide the range 1-500 into 50
> exponentially-spaced buckets -- can you check that the buckets generated
> here are reasonable?

It seems to work reasonably well for me: http://i.imgur.com/KurFR.png

What were your concerns?

Comment 6

[Justin Lebar (not reading bugmail)]

Comment on attachment 552452 [details] [diff] [review]
Record the time from starting a decode on draw and actually finishing.

Maybe we want to report sync and async decodes separately?

Comment 7

[Justin Lebar (not reading bugmail)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> It seems to work reasonably well for me: http://i.imgur.com/KurFR.png
> 
> What were your concerns?

I was concerned it might not space the buckets reasonably, but the buckets in that screenshot look good to me!

Comment 8

[Jeff Muizelaar [:jrmuizel]]

(In reply to Justin Lebar [:jlebar] (out 8/12 - 8/21) from comment #6)
> Comment on attachment 552452 [details] [diff] [review]
> Record the time from starting a decode on draw and actually finishing.
> 
> Maybe we want to report sync and async decodes separately?

Maybe. This is the more user visible thing so I'd like to start with that.

Comment 9

[Justin Lebar (not reading bugmail)]

Comment on attachment 552452 [details] [diff] [review]
Record the time from starting a decode on draw and actually finishing.

Discussed briefly on IRC:

<jrmuizel_> what I meant is the async/sync thing is more an implementation detail
<jrmuizel_> I want to measure the time until the user gets to see the images they wanted
<jrmuizel_> I don't really care if the browser is responsive inbetween
<jrmuizel_> [whether the browser is responsive] would still be a useful measurement, just not what I wanted to measure this time

r=me

Comment 10

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/3274828eccfb
https://hg.mozilla.org/mozilla-central/rev/4b4b359e77e4