Add StackBench to measure performance on stack-like (fixed element size) work loads.

Add StackBench to measure performance on stack-like (fixed element size) work loads.

BUG=303282
Committed: http://code.google.com/p/skia/source/detail?r=12940

[mtklein, 2014-01-06 21:54:57]

Sadly, my new data structure was strictly worse than SkTDArray, so I ditched it.
 All hail SkTDArray!

[caryclark, 2014-01-06 22:05:20]

some nits, but lgtm

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp
File bench/StackBench.cpp (right):

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:1: #include "SkBenchmark.h"
copyright at top?

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:2: #include "SkRandom.h"
alphabetized?

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:48: while(void* p = it.next()) {
some compilers are going to want extra parens here, I'm pretty sure

[mtklein_C, 2014-01-07 15:41:13]

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp
File bench/StackBench.cpp (right):

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:1: #include "SkBenchmark.h"
On 2014/01/06 22:05:21, caryclark wrote:
> copyright at top?

Done.

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:2: #include "SkRandom.h"
On 2014/01/06 22:05:21, caryclark wrote:
> alphabetized?

Was trying to keep support code and data-structures-under-test in distinct
(alphabetized) sections.  I don't mind shoving it all together if you feel
strongly.

https://codereview.chromium.org/110893007/diff/70001/bench/StackBench.cpp#new...
bench/StackBench.cpp:48: while(void* p = it.next()) {
On 2014/01/06 22:05:21, caryclark wrote:
> some compilers are going to want extra parens here, I'm pretty sure

I think this will be OK.  Clang, who usually wants extra parens, won't complain
because this doesn't actually fit the pattern of the bug it's trying to prevent.
 The type declaration makes it unambiguous.

void* p;
while(p = it.next())  { ... } -> -Wparentheses wants extra parens, because
either = or == could compile.

while(void* p = it.next()) { ... } -> -Wparentheses doesn't trigger, because ==
doesn't make sense.

[bsalomon, 2014-01-07 15:54:27]

lgtm, curious whether TArray could be updated to perform like TDArray.

[mtklein, 2014-01-07 16:02:22]

On 2014/01/07 15:54:27, bsalomon wrote:
> lgtm, curious whether TArray could be updated to perform like TDArray.

Yep, next thing I'm going to look at.  Either we update TArray<T, true> to be
the same as TDArray (which means, removing guarantees of constructor, destructor
for POD types, which TArray guarantees now) or we make TDArray optionally call
constructors and destructors with a new bool template parameter.  It's sort of
easier to modify TDArray, because we'd just be adding a new mode instead of
changing existing semantics.  I'm worried I wouldn't be able to catch the places
where TArray<T, true> currently relies on the default initialization.

[commit-bot: I haz the power, 2014-01-07 16:05:44]

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

[commit-bot: I haz the power, 2014-01-07 17:03:34]

Change committed as 12940