Last Comment Bug 678258 - More image decoding telemetry
: More image decoding telemetry
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: ImageLib (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla8
Assigned To: Jeff Muizelaar [:jrmuizel]
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-11 11:31 PDT by Jeff Muizelaar [:jrmuizel]
Modified: 2011-08-12 08:03 PDT (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Record the time from starting a decode on draw and actually finishing. (3.97 KB, patch)
2011-08-11 11:38 PDT, Jeff Muizelaar [:jrmuizel]
justin.lebar+bug: review+
Details | Diff | Splinter Review
Record the number of chunks that we decode per trip through the event loop. (3.52 KB, patch)
2011-08-11 11:42 PDT, Jeff Muizelaar [:jrmuizel]
justin.lebar+bug: review+
Details | Diff | Splinter Review

Description Jeff Muizelaar [:jrmuizel] 2011-08-11 11:31:23 PDT

    
Comment 1 Jeff Muizelaar [:jrmuizel] 2011-08-11 11:38:59 PDT
Created attachment 552452 [details] [diff] [review]
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] 2011-08-11 11:42:56 PDT
Created attachment 552453 [details] [diff] [review]
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) 2011-08-11 11:51:21 PDT
(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) 2011-08-11 12:00:09 PDT
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] 2011-08-11 12:21:24 PDT
(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) 2011-08-11 12:21:44 PDT
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) 2011-08-11 12:22:58 PDT
(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] 2011-08-11 12:34:23 PDT
(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) 2011-08-11 12:47:48 PDT
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

Note You need to log in before you can comment on or make changes to this bug.