Copy SharedBuffer before calling decodeImageData

Copy SharedBuffer before calling decodeImageData

With the existing JPEG code, the call to data() will copy all segments
in the SharedBuffer together. When timing multiple iterations, only the
first call does this, since the segments have already been copied.

In order to get a more reasonable picture of how long the call to decode()
takes, use a new SharedBuffer for each call to decodeImageData().

BUG=467772

[scroggo_chromium, 2015-07-23 21:42:07]

scroggo@chromium.org changed reviewers:
+ noel@chromium.org

[scroggo_chromium, 2015-07-23 21:42:08]

I tested this on the set of images you sent me (the jpeg ones), and this makes
the test take longer, as expected, because now each call to decode requires
merging all the buffers together.

I put up a spreadsheet here [1]. The relevant bits are the first four columns on
page one, which show how long it takes to decode each image (in total - 1000
iterations) and on average, using the checked in version of the test, and the
first four columns on page 2, which show the same timing information using this
version of the test. When I say it "take[s] longer", I mean that the total time
took longer, but maybe there is a smarter way to tally all the images? I also
included file size, in case it's interesting to compare across file size.

(FWIW, the right set of columns on both pages is with my yet-to-be-uploaded
change which avoids copying in JPEGImageDecoder, which looks worse running the
existing version of the test, since the existing version of JPEGImageDecoder is
not being timed fairly - each iteration after the first need not copy. I'll
upload that CL once I have the tests in the right place and run the layout tests
to confirm I have not broken anything. So those numbers may be premature but I
think hint that it might be beneficial.)


[1]
https://docs.google.com/a/google.com/spreadsheets/d/1l4gWB_S5oG6WEKrGx6ltBAiX...

[scroggo_chromium, 2015-09-04 16:10:36]

On 2015/07/23 21:42:08, scroggo_chromium wrote:
> I tested this on the set of images you sent me (the jpeg ones), and this makes
> the test take longer, as expected, because now each call to decode requires
> merging all the buffers together.
> 
> I put up a spreadsheet here [1]. The relevant bits are the first four columns
on
> page one, which show how long it takes to decode each image (in total - 1000
> iterations) and on average, using the checked in version of the test, and the
> first four columns on page 2, which show the same timing information using
this
> version of the test. When I say it "take[s] longer", I mean that the total
time
> took longer, but maybe there is a smarter way to tally all the images? I also
> included file size, in case it's interesting to compare across file size.
> 
> (FWIW, the right set of columns on both pages is with my yet-to-be-uploaded
> change which avoids copying in JPEGImageDecoder, which looks worse running the
> existing version of the test, since the existing version of JPEGImageDecoder
is
> not being timed fairly - each iteration after the first need not copy. I'll
> upload that CL once I have the tests in the right place and run the layout
tests
> to confirm I have not broken anything. So those numbers may be premature but I
> think hint that it might be beneficial.)
> 
> 
> [1]
>
https://docs.google.com/a/google.com/spreadsheets/d/1l4gWB_S5oG6WEKrGx6ltBAiX...

Replaced by crrev.com/1318713005