Add bench_record.

Add bench_record.
    
I got fed up trying to figure out how best to measure recording cost with bench_pictures, render_pictures, etc, so I wrote a new tool.

Features welcome.

BUG=

Committed: http://code.google.com/p/skia/source/detail?r=13037

[tomhudson, 2014-01-13 11:55:27]

lgtm

LGTM. Questions are just curiosity.

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp
File tools/bench_record.cpp (right):

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:21: // recording, and this should take ~20 seconds to
run.
How wildly different will this be on different platforms?

I guess the point here is to let perf capture data not dominated by loading
costs, the way it is on other benchmarks? Since it looks like your timing is
only around the rerecording, that number ought to be clean.

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:26: DEFINE_bool(endRecording, true, "If false, don't time
SkPicture::endRecording()");
Why would you ever want to do that? endRecording() time is significant.

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:28: int tool_main(int argc, char** argv);
Looks like this is an iOS thing? I don't recall seeing it before in the Skia
style.

[commit-bot: I haz the power, 2014-01-13 11:55:32]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/132573002/40001

[commit-bot: I haz the power, 2014-01-13 12:03:52]

Change committed as 13037

[mtklein_C, 2014-01-13 13:29:26]

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp
File tools/bench_record.cpp (right):

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:21: // recording, and this should take ~20 seconds to
run.
On 2014/01/13 11:55:27, tomhudson wrote:
> How wildly different will this be on different platforms?
> 
> I guess the point here is to let perf capture data not dominated by loading
> costs, the way it is on other benchmarks? Since it looks like your timing is
> only around the rerecording, that number ought to be clean.

As wildly as CPUs and memory bandwidth vary.  On my laptop it takes ~30s. 
Haven't even tried on a phone yet, but I'd guess it's a couple minutes with
--loops 900.

The idea is entirely to amortize away the time it takes to read the picture so
it stays out of the way in in perf / Instruments.  If you know what you're
looking for in the profile, it should be fine to run with a much lower count,
like --loops 10.

I don't tend to look at the numbers we print out as much more than a sanity
check and a progress indicator, but you're right they don't time reading
pictures.  They should be stable with decreasing precision as --loops decreases.

I actually started with a version that ran the benchmarks in parallel.  This
gives you the same profile much faster, but at the cost of very misleading times
printed out on the screen (these are wall-timers I'm using here, not
CPU-timers).  If it would be useful to get a profile faster (down around 2-3s
IIRC),  then maybe we can add that back in as an option and have it just hide
the output when using more than one thread.

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:26: DEFINE_bool(endRecording, true, "If false, don't time
SkPicture::endRecording()");
On 2014/01/13 11:55:27, tomhudson wrote:
> Why would you ever want to do that? endRecording() time is significant.

Conceivably, we could move what's done there to another thread, so
--noendRecording lets you measure the absolute recording critical path.

https://codereview.chromium.org/132573002/diff/40001/tools/bench_record.cpp#n...
tools/bench_record.cpp:28: int tool_main(int argc, char** argv);
On 2014/01/13 11:55:27, tomhudson wrote:
> Looks like this is an iOS thing? I don't recall seeing it before in the Skia
> style.

Yeah, all our tools do it.  We have a little shell on iOS that wraps each of our
tools and calls tool_main to run.  I don't think anyone actually uses it; this
is just to make buildbots happy.