status-im/mobile
2
0
Fork 0
mirror of synced 2025-02-24 07:18:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
mobile/bind/testdata/benchmark/benchmark.go

172 lines
6.8 KiB
Go
Raw Normal View History

mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
// Copyright 2016 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
mobile/bind: update benchmarks to address post-submit review comments Address comment from CL/20095. Change-Id: I2b3b3230106ad27128440609472003c69bd97825 Reviewed-on: https://go-review.googlesource.com/20173 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-03 13:34:38 +01:00
// Package benchmark contains benchmarking bound functions for internal use.
package benchmark
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
import (
"log"
"time"
)
type Benchmarks interface {
// It seems to be much faster to call a native function from Java
// when there is already a native call earlier in the stack.
mobile/bind: update benchmarks to address post-submit review comments Address comment from CL/20095. Change-Id: I2b3b3230106ad27128440609472003c69bd97825 Reviewed-on: https://go-review.googlesource.com/20173 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-03 13:34:38 +01:00
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
// Run runs a named benchmark from a different thread, with
// no native call prior in the stack.
Run(name string, n int)
// RunDirect runs a named benchmark directly, with the native
// context from the call itself.
RunDirect(name string, n int)
// Callbacks for Go benchmarks
NewI() I
Noargs()
Onearg(_ int)
Oneret() int
Ref(_ I)
Manyargs(_, _, _, _, _, _, _, _, _, _ int)
String(_ string)
mobile/bind: avoid intermediate []rune copy converting Java string to Go Converting a Go string to a string suitable use a specialized function, UTF16Encode, that can encode the string directly to a malloc'ed buffer. That way, only two copies are made when strings are passed from Go to Java; once for UTF-8 to UTF-16 encoding and once for the creation of the Java String. This CL implements the same optimization in the other direction, with a UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a Go decoder also saves the extra copy, the Cgo overhead makes the calls much slower for short strings. To alleviate the risk of introducing decoding bugs, I've added the tests from the encoding/utf16 package to SeqTest. As a sideeffect, both Java and ObjC now always copy strings, regardless of the argument mode. The cpy argument can therefore be removed from the string conversion functions. Furthermore, the modeRetained and modeReturned modes can be collapsed into just one. While we're here, delete a leftover function from seq/strings.go that wasn't removed when the old seq buffers went away. Benchmarks, as compared with benchstat over 5 runs: name old time/op new time/op delta JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5) JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5) JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5) JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5) JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5) JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5) JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5) JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5) JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5) JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5) JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5) JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5) GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5) GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5) GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5) GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5) GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5) GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5) Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937 Reviewed-on: https://go-review.googlesource.com/20250 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-04 17:59:04 +01:00
StringRetShort() string
StringRetLong() string
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
Slice(_ []byte)
}
type (
I interface {
F()
}
AnI struct {
}
)
func (_ *AnI) F() {
}
func NewI() I {
return new(AnI)
}
func runBenchmark(name string, f func(n int)) {
// Run once for warmup
f(1)
n := 1000
var dt time.Duration
minDuration := 1 * time.Second
for dt < minDuration {
n *= 2
t0 := time.Now()
f(n)
dt = time.Since(t0)
}
log.Printf("Benchmark%s %d %d ns/op\n", name, n, dt.Nanoseconds()/int64(n))
}
func runGoBenchmark(name string, f func()) {
runBenchmark("Go"+name, func(n int) {
for i := 0; i < n; i++ {
f()
}
})
runBenchmark("Go"+name+"Direct", func(n int) {
done := make(chan struct{})
go func() {
for i := 0; i < n; i++ {
f()
}
close(done)
}()
<-done
})
}
func RunBenchmarks(b Benchmarks) {
names := []string{
"Empty",
"Noargs",
"Onearg",
"Oneret",
"Manyargs",
mobile/bind: implement iOS benchmarks Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks package on iOS. While we're here, replace "Java" with "Foreign" in test names to reflect that benchmarks run on both platforms now. Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3 Reviewed-on: https://go-review.googlesource.com/20259 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-06 14:16:38 +01:00
"Refforeign",
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
"Refgo",
"StringShort",
"StringLong",
"StringShortUnicode",
"StringLongUnicode",
mobile/bind: avoid intermediate []rune copy converting Java string to Go Converting a Go string to a string suitable use a specialized function, UTF16Encode, that can encode the string directly to a malloc'ed buffer. That way, only two copies are made when strings are passed from Go to Java; once for UTF-8 to UTF-16 encoding and once for the creation of the Java String. This CL implements the same optimization in the other direction, with a UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a Go decoder also saves the extra copy, the Cgo overhead makes the calls much slower for short strings. To alleviate the risk of introducing decoding bugs, I've added the tests from the encoding/utf16 package to SeqTest. As a sideeffect, both Java and ObjC now always copy strings, regardless of the argument mode. The cpy argument can therefore be removed from the string conversion functions. Furthermore, the modeRetained and modeReturned modes can be collapsed into just one. While we're here, delete a leftover function from seq/strings.go that wasn't removed when the old seq buffers went away. Benchmarks, as compared with benchstat over 5 runs: name old time/op new time/op delta JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5) JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5) JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5) JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5) JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5) JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5) JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5) JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5) JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5) JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5) JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5) JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5) GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5) GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5) GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5) GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5) GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5) GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5) Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937 Reviewed-on: https://go-review.googlesource.com/20250 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-04 17:59:04 +01:00
"StringRetShort",
"StringRetLong",
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
"SliceShort",
"SliceLong",
}
for _, name := range names {
mobile/bind: implement iOS benchmarks Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks package on iOS. While we're here, replace "Java" with "Foreign" in test names to reflect that benchmarks run on both platforms now. Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3 Reviewed-on: https://go-review.googlesource.com/20259 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-06 14:16:38 +01:00
runBenchmark("Foreign"+name, func(n int) {
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
b.Run(name, n)
})
mobile/bind: implement iOS benchmarks Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks package on iOS. While we're here, replace "Java" with "Foreign" in test names to reflect that benchmarks run on both platforms now. Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3 Reviewed-on: https://go-review.googlesource.com/20259 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-06 14:16:38 +01:00
runBenchmark("Foreign"+name+"Direct", func(n int) {
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
b.RunDirect(name, n)
})
}
runGoBenchmark("Empty", func() {})
runGoBenchmark("Noarg", func() { b.Noargs() })
runGoBenchmark("Onearg", func() { b.Onearg(0) })
runGoBenchmark("Oneret", func() { b.Oneret() })
mobile/bind: implement iOS benchmarks Add a XCTestCase based ObjC driver, SeqTest.m, to run the benchmarks package on iOS. While we're here, replace "Java" with "Foreign" in test names to reflect that benchmarks run on both platforms now. Change-Id: I38a38f3093b4b97961107b5ea66f03cff8e395c3 Reviewed-on: https://go-review.googlesource.com/20259 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2016-03-06 14:16:38 +01:00
foreignRef := b.NewI()
runGoBenchmark("Refforeign", func() { b.Ref(foreignRef) })
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
goRef := NewI()
runGoBenchmark("Refgo", func() { b.Ref(goRef) })
runGoBenchmark("Manyargs", func() { b.Manyargs(0, 0, 0, 0, 0, 0, 0, 0, 0, 0) })
runGoBenchmark("StringShort", func() { b.String(ShortString) })
runGoBenchmark("StringLong", func() { b.String(LongString) })
runGoBenchmark("StringShortUnicode", func() { b.String(ShortStringUnicode) })
runGoBenchmark("StringLongUnicode", func() { b.String(LongStringUnicode) })
mobile/bind: avoid intermediate []rune copy converting Java string to Go Converting a Go string to a string suitable use a specialized function, UTF16Encode, that can encode the string directly to a malloc'ed buffer. That way, only two copies are made when strings are passed from Go to Java; once for UTF-8 to UTF-16 encoding and once for the creation of the Java String. This CL implements the same optimization in the other direction, with a UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a Go decoder also saves the extra copy, the Cgo overhead makes the calls much slower for short strings. To alleviate the risk of introducing decoding bugs, I've added the tests from the encoding/utf16 package to SeqTest. As a sideeffect, both Java and ObjC now always copy strings, regardless of the argument mode. The cpy argument can therefore be removed from the string conversion functions. Furthermore, the modeRetained and modeReturned modes can be collapsed into just one. While we're here, delete a leftover function from seq/strings.go that wasn't removed when the old seq buffers went away. Benchmarks, as compared with benchstat over 5 runs: name old time/op new time/op delta JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5) JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5) JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5) JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5) JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5) JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5) JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5) JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5) JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5) JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5) JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5) JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5) GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5) GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5) GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5) GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5) GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5) GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5) Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937 Reviewed-on: https://go-review.googlesource.com/20250 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-04 17:59:04 +01:00
runGoBenchmark("StringRetShort", func() { b.StringRetShort() })
runGoBenchmark("StringRetLong", func() { b.StringRetLong() })
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
runGoBenchmark("SliceShort", func() { b.Slice(ShortSlice) })
runGoBenchmark("SliceLong", func() { b.Slice(LongSlice) })
}
func Noargs() {
}
func Onearg(_ int) {
}
func Manyargs(_, _, _, _, _, _, _, _, _, _ int) {
}
func Oneret() int {
return 0
}
func String(_ string) {
}
mobile/bind: avoid intermediate []rune copy converting Java string to Go Converting a Go string to a string suitable use a specialized function, UTF16Encode, that can encode the string directly to a malloc'ed buffer. That way, only two copies are made when strings are passed from Go to Java; once for UTF-8 to UTF-16 encoding and once for the creation of the Java String. This CL implements the same optimization in the other direction, with a UTF-16 to UTF-8 decoder implemented in C. Unfortunately, while calling into a Go decoder also saves the extra copy, the Cgo overhead makes the calls much slower for short strings. To alleviate the risk of introducing decoding bugs, I've added the tests from the encoding/utf16 package to SeqTest. As a sideeffect, both Java and ObjC now always copy strings, regardless of the argument mode. The cpy argument can therefore be removed from the string conversion functions. Furthermore, the modeRetained and modeReturned modes can be collapsed into just one. While we're here, delete a leftover function from seq/strings.go that wasn't removed when the old seq buffers went away. Benchmarks, as compared with benchstat over 5 runs: name old time/op new time/op delta JavaStringShort 11.4µs ±13% 11.6µs ± 4% ~ (p=0.859 n=10+5) JavaStringShortDirect 19.5µs ± 9% 20.3µs ± 2% +3.68% (p=0.019 n=9+5) JavaStringLong 103µs ± 8% 24µs ± 4% -77.13% (p=0.001 n=9+5) JavaStringLongDirect 113µs ± 9% 32µs ± 7% -71.63% (p=0.001 n=9+5) JavaStringShortUnicode 11.1µs ±16% 10.7µs ± 5% ~ (p=0.190 n=9+5) JavaStringShortUnicodeDirect 19.6µs ± 7% 20.2µs ± 1% +2.78% (p=0.029 n=9+5) JavaStringLongUnicode 97.1µs ± 9% 28.0µs ± 5% -71.17% (p=0.001 n=9+5) JavaStringLongUnicodeDirect 105µs ±10% 34µs ± 5% -67.23% (p=0.002 n=8+5) JavaStringRetShort 14.2µs ± 2% 13.9µs ± 1% -2.15% (p=0.006 n=8+5) JavaStringRetShortDirect 20.8µs ± 2% 20.4µs ± 2% ~ (p=0.065 n=8+5) JavaStringRetLong 42.2µs ± 9% 42.4µs ± 3% ~ (p=0.190 n=9+5) JavaStringRetLongDirect 51.2µs ±21% 50.8µs ± 8% ~ (p=0.518 n=9+5) GoStringShort 23.4µs ± 7% 22.5µs ± 3% -3.55% (p=0.019 n=9+5) GoStringLong 51.9µs ± 9% 53.1µs ± 3% ~ (p=0.240 n=9+5) GoStringShortUnicode 24.2µs ± 6% 22.8µs ± 1% -5.54% (p=0.002 n=9+5) GoStringLongUnicode 58.6µs ± 8% 57.6µs ± 3% ~ (p=0.518 n=9+5) GoStringRetShort 27.6µs ± 1% 23.2µs ± 2% -15.87% (p=0.003 n=7+5) GoStringRetLong 129µs ±12% 33µs ± 2% -74.03% (p=0.001 n=10+5) Change-Id: Icb9481981493ffca8defed9fb80a9433d6048937 Reviewed-on: https://go-review.googlesource.com/20250 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-04 17:59:04 +01:00
func StringRetShort() string {
return ShortString
}
func StringRetLong() string {
return LongString
}
mobile/bind: add Android benchmarks Since the normal Go benchmark machinery cannot readily be used for Android apps, a new test, TestJavaSeqBench, is added that builds and runs the new benchmarkpkg package along with its support Java class SeqBench. Benchmarkpkg mimics Go benchmarking, in particular it produces benchcmp compatible output. Excerpts of the output from a Nexus 5: BenchmarkJavaEmpty 65536000 26 ns/op BenchmarkJavaNoargs 256000 7685 ns/op BenchmarkJavaNoargsDirect 64000 17405 ns/op BenchmarkJavaOnearg 64000 26887 ns/op BenchmarkJavaOneret 32000 38325 ns/op BenchmarkJavaManyargs 32000 41720 ns/op BenchmarkJavaRefjava 32000 38139 ns/op BenchmarkJavaRefgo 32000 34403 ns/op BenchmarkJavaStringShort 32000 32366 ns/op BenchmarkJavaStringLong 8000 127879 ns/op BenchmarkJavaSliceShort 32000 42462 ns/op BenchmarkJavaSliceLong 8000 138391 ns/op BenchmarkGoEmpty 524288000 3 ns/op BenchmarkGoNoarg 32000 40342 ns/op BenchmarkGoOnearg 32000 43529 ns/op BenchmarkGoOneret 32000 45456 ns/op BenchmarkGoRefjava 32000 55111 ns/op BenchmarkGoRefgo 32000 57038 ns/op BenchmarkGoManyargs 16000 67967 ns/op BenchmarkGoStringShort 32000 57538 ns/op BenchmarkGoStringLong 8000 128485 ns/op BenchmarkGoSliceShort 32000 59279 ns/op BenchmarkGoSliceLong 4000 411225 ns/op Benchmarks prefixed with "BenchmarkJava" are for calls from Java into Go. Benchmarks prefixed with "BenchmarksGo" are the other way around. Note that all Go benchmarks run against a Java interface implementation while the Java benchmarks calls Go functions directly. In other words, every Go call serializes an implicit Java reference, explaining the higher call times. The JavaRefgo and JavaRefjava tests attempt to quantify the overhead equivalent for Java. The "Direct" suffix are for variants that runs the benchmarks from a new thread or goroutine. For Go it makes little difference, but there is a noticable speedup when calling Go from Java when there is already a JNI call context earlier in the stack. The benchmarks are for Android only for now, but the benchmarkpkg has been added to the common golang.org/x/mobile/bind package in anticipation of future iOS support. Change-Id: I3c948dc710b65bc348e7635416324095060a5beb Reviewed-on: https://go-review.googlesource.com/20095 Reviewed-by: David Crawshaw <crawshaw@golang.org>
2016-03-02 11:50:19 +01:00
func Slice(_ []byte) {
}
func Ref(_ I) {
}
var (
ShortSlice = make([]byte, 10)
LongSlice = make([]byte, 100000)
)
const (
ShortString = "Hello, World!"
LongString = "Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World! Hello, World!, World!"
ShortStringUnicode = "Hello, 世界!"
LongStringUnicode = "Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界! Hello, 世界!, 世界!"
)
Reference in New Issue Copy Permalink