Only the YCbCr benchmarks show significant changes. The other benchmark
changes look noisy. The PixOffset and YOffset calls were previously
already inlined by the gc compiler. COffset was different because it's
more complicated than YOffset, and the switch inside the COffset body is
redundant when you already know the src image sratio.
http://golang.org/src/image/ycbcr.go?s=2377:2414#L77
benchmark old ns/op new ns/op delta
BenchmarkScaleLargeDownNN 1037504 908236 -12.46%
BenchmarkScaleLargeDownAB 3196568 2735776 -14.42%
BenchmarkScaleLargeDownBL 357165552 311463393 -12.80%
BenchmarkScaleLargeDownCR 649403305 544985134 -16.08%
BenchmarkScaleSrcYCbCr 3204063 2699147 -15.76%
BenchmarkTformABSrcYCbCr 2155142 1968540 -8.66%
BenchmarkTformCRSrcYCbCr 11672625 9865358 -15.48%
Change-Id: Ifa109363a1282ab114b2fdb0b577dcafef927333
Reviewed-on: https://go-review.googlesource.com/7880
Reviewed-by: Rob Pike <r@golang.org>
benchmark old ns/op new ns/op delta
BenchmarkTformCRSrcGray 6111610 5344117 -12.56%
BenchmarkTformCRSrcNRGBA 62070281 59295178 -4.47%
BenchmarkTformCRSrcRGBA 13840290 10612547 -23.32%
BenchmarkTformCRSrcUniform 591637 587621 -0.68%
BenchmarkTformCRSrcYCbCr 72219184 69404747 -3.90%
As of current origin/master, Gray and RGBA have fast paths but the other src
image types do not. They have more fat, so the relative improvement is smaller.
Change-Id: Ibbae91cd3cb3c139efb1dcc8fda1cb6432505189
Reviewed-on: https://go-review.googlesource.com/7794
Reviewed-by: Rob Pike <r@golang.org>
These code paths aren't actually fast yet. That will be a follow-up
change.
Change-Id: I814992573cc6af422e49d0ddf336003e662897a5
Reviewed-on: https://go-review.googlesource.com/7791
Reviewed-by: Rob Pike <r@golang.org>
Also fix the NN and ABL fast paths to only apply if we can access the
Pix elements without src-bounds checking.
Change-Id: Ie9fc96b28e0665df49d00c4c53cb81385faee4db
Reviewed-on: https://go-review.googlesource.com/7675
Reviewed-by: Rob Pike <r@golang.org>
I simply forgot to do this in the previous change.
Change-Id: I0ea5d6bb0a09154cb995a665476ffceb155bd49e
Reviewed-on: https://go-review.googlesource.com/7651
Reviewed-by: Rob Pike <r@golang.org>
Just stub implementations for now. Actual implementations will be
follow-up changes.
Change-Id: Id21d9042a2073c2dc0f78c9977c4940f000a41df
Reviewed-on: https://go-review.googlesource.com/6805
Reviewed-by: Rob Pike <r@golang.org>
This means that only Kernel values have a NewScaler method, which
re-uses computation when scaling multiple images of the same dst and src
dimensions. The NearestNeighbor and ApproxBiLinear scalers don't get any
pre-computation to re-use, so don't need a NewScaler method just to
satisfy the previous Interpolator interface. As a small bonus, NN.Scale
and ABL.Scale should no longer allocate on the fast paths.
This change is consistent the upcoming Transformer method, so that the
Interpolator interface will be
type Interpolator interface {
Scale(etc)
Transform(etc)
}
instead of
type Interpolator interface {
NewScaler(etc) Scaler
Transform(etc)
}
I don't have a good theory for why the "func (ablInterpolator)
scale_RGBA_RGBA" benchmark is such a dramatic improvement, but at least
it's in the right direction. I'm calling the other benchmark changes as
noise.
benchmark old ns/op new ns/op delta
BenchmarkScaleLargeDownNN 3233406 3169060 -1.99%
BenchmarkScaleLargeDownAB 12018178 12011348 -0.06%
BenchmarkScaleLargeDownBL 1420827834 1409335695 -0.81%
BenchmarkScaleLargeDownCR 2820669690 2795534035 -0.89%
BenchmarkScaleDownNN 866628 869241 +0.30%
BenchmarkScaleDownAB 3175963 3216041 +1.26%
BenchmarkScaleDownBL 26639767 26677003 +0.14%
BenchmarkScaleDownCR 51720996 51621628 -0.19%
BenchmarkScaleUpNN 42758485 43258611 +1.17%
BenchmarkScaleUpAB 156693813 156943367 +0.16%
BenchmarkScaleUpBL 69511444 69621698 +0.16%
BenchmarkScaleUpCR 124530191 124885601 +0.29%
BenchmarkScaleSrcGray 8992205 9129321 +1.52%
BenchmarkScaleSrcNRGBA 9807837 9894466 +0.88%
BenchmarkScaleSrcRGBA 1333188 1104282 -17.17%
BenchmarkScaleSrcUniform 1147788 1162488 +1.28%
BenchmarkScaleSrcYCbCr 12164542 12305373 +1.16%
Change-Id: I2aee6c392eb7437e843260775aed97ce145b4d47
Reviewed-on: https://go-review.googlesource.com/6556
Reviewed-by: Rob Pike <r@golang.org>
This will lessen the diff in a follow-up change.
Change-Id: I67257b935e4b5fc6fcc462c83910a3f09f26702f
Reviewed-on: https://go-review.googlesource.com/6554
Reviewed-by: David Symonds <dsymonds@golang.org>
Optimizing this code path will be follow-up changes.
Change-Id: Ifece6c7d3685bb8f2d20cf8828a121c9ff346434
Reviewed-on: https://go-review.googlesource.com/6238
Reviewed-by: Rob Pike <r@golang.org>
Adding fast paths for concrete dst and src image types will be follow-up
changes.
Change-Id: Ib23e3cc46d9c7a52ebd5eddfbad09177b0b421af
Reviewed-on: https://go-review.googlesource.com/5417
Reviewed-by: Rob Pike <r@golang.org>
This is just a copy/paste/rename in anticipation of automatically
generating fast-path code for specific dst-image types and src-image
types, a la the standard library's image/draw package.
Change-Id: If6385b347cb5e1d134b0ce841ef38ed4450a6fef
Reviewed-on: https://go-review.googlesource.com/5252
Reviewed-by: David Symonds <dsymonds@golang.org>
