Optimize SkRect::sort()

Optimize SkRect::sort()

This optimization can reduce comparison and assignments. For
geo_rect_sort benchmark, performance improved to 1.63us from 3.28us.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/fb502f072f5a32ad122bfc2717fe56a3c22e482e

[qiankun, 2014-11-03 08:48:52]

qiankun.miao@intel.com changed reviewers:
+ reed@google.com

[qiankun, 2014-11-03 08:51:26]

Hi reed, I found the previous SkRect::sort() implementation is faster as the
data on my desktop (Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz). Could you have a
check?

[reed1, 2014-11-03 22:02:03]

reed@google.com changed reviewers:
+ mtklein@google.com

[reed1, 2014-11-03 22:02:03]

interesting -- this is what the old version did (but in the .cpp not the
header). I agree it is faster (on my macbook).

mtklein -- any thoughts?
qiankun -- have you timed this on android/arm?

[mtklein, 2014-11-03 22:16:07]

On 2014/11/03 22:02:03, reed1 wrote:
> interesting -- this is what the old version did (but in the .cpp not the
> header). I agree it is faster (on my macbook).
> 
> mtklein -- any thoughts?
> qiankun -- have you timed this on android/arm?

The performance of a lot of these helpers is going to depend on the call site's
bias.  E.g., for intersects, is it faster to check L<R first or T<B first?  In
those scenarios, it's probably best to leave something simple in SkRect and
write a custom little static method inline.

But, in this case, I'm having trouble coming up with a scenario where this new
code isn't just better.   If it's likely they're already sorted, this new one
will certainly be faster, because it skips any writes back to memory.  Even if
it's unlikely they're already sorted, I'd still be pretty surprised if the
version on the left were faster if we're doing a lot of these.  Branch
prediction can pick up the "likely sorted" and "likely not sorted" biases in
both x and y very easily, and it's always worth a branch to avoid a write.

[reed1, 2014-11-03 22:24:14]

The CQ bit was checked by reed@google.com

[reed1, 2014-11-03 22:24:14]

lgtm

[commit-bot: I haz the power, 2014-11-03 22:25:21]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/695443005/20001

[commit-bot: I haz the power, 2014-11-03 22:34:34]

Committed patchset #2 (id:20001) as fb502f072f5a32ad122bfc2717fe56a3c22e482e

[qiankun, 2014-11-04 07:28:30]

On 2014/11/03 22:02:03, reed1 wrote:
> interesting -- this is what the old version did (but in the .cpp not the
> header). I agree it is faster (on my macbook).
> 
> mtklein -- any thoughts?
> qiankun -- have you timed this on android/arm?

This data is 37.7µs vs. 55.8µs on Nexus 4.