Some fixes for SortBench

1) Don't allocate 100,000 ints when we only need 1,000.
2) Don't sort past the end of the array when using SkTQSort.
3) Don't allocate any arrays until we need them (in onDraw).

Also, propagate the constant N everywhere through the bench.

BUG=
R=bungeman@google.com

Committed: https://code.google.com/p/skia/source/detail?r=11329

[bungeman-skia, 2013-09-17 19:16:10]

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp
File bench/SortBench.cpp (right):

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcode15
bench/SortBench.cpp:15: static void rand_proc(int array[]) {
If we're not passing count, can we make this 'int array[N]'?

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcod...
bench/SortBench.cpp:116: SkAutoTMalloc<int> unsorted(N), sorted(N);
generally we try to avoid multiple declarations on one line

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcod...
bench/SortBench.cpp:117: gRec[fType].fProc(unsorted.get());
it seems unfortunate to put this inside the timed part of this. I'm sure the
'rand' version is much slower than the 'same' version. Does this all work itself
out in the end with the new setup?

[mtklein, 2013-09-17 19:26:03]

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp
File bench/SortBench.cpp (right):

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcode15
bench/SortBench.cpp:15: static void rand_proc(int array[]) {
On 2013/09/17 19:16:10, bungeman1 wrote:
> If we're not passing count, can we make this 'int array[N]'?

Done.

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcod...
bench/SortBench.cpp:116: SkAutoTMalloc<int> unsorted(N), sorted(N);
On 2013/09/17 19:16:10, bungeman1 wrote:
> generally we try to avoid multiple declarations on one line

Done.

https://codereview.chromium.org/23890033/diff/6001/bench/SortBench.cpp#newcod...
bench/SortBench.cpp:117: gRec[fType].fProc(unsorted.get());
On 2013/09/17 19:16:10, bungeman1 wrote:
> it seems unfortunate to put this inside the timed part of this. I'm sure the
> 'rand' version is much slower than the 'same' version. Does this all work
itself
> out in the end with the new setup?

Yeah, probably wouldn't hurt now, but we might as well use onPreDraw() given
that we've got that perfect hook.

[bungeman-skia, 2013-09-17 19:35:21]

lgtm

[mtklein, 2013-09-17 19:37:38]

Committed patchset #4 manually as r11329 (presubmit successful).