2
0
mirror of synced 2025-02-23 23:08:14 +00:00
mobile/bind/java/SeqBench.java

163 lines
4.5 KiB
Java
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.
package go;
import android.test.InstrumentationTestCase;
import android.util.Log;
import java.util.Map;
import java.util.HashMap;
import java.util.concurrent.Executors;
import java.util.concurrent.ExecutorService;
import go.benchmark.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
public class SeqBench extends InstrumentationTestCase {
public static class AnI implements Benchmark.I {
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
@Override public void F() {
}
}
private static class Benchmarks implements Benchmark.Benchmarks {
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
private static Map<String, Runnable> benchmarks;
private static ExecutorService executor = Executors.newSingleThreadExecutor();
static {
benchmarks = new HashMap<String, Runnable>();
benchmarks.put("Empty", new Runnable() {
@Override public void run() {
}
});
benchmarks.put("Noargs", new Runnable() {
@Override public void run() {
Benchmark.Noargs();
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
}
});
benchmarks.put("Onearg", new Runnable() {
@Override public void run() {
Benchmark.Onearg(0);
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
}
});
benchmarks.put("Manyargs", new Runnable() {
@Override public void run() {
Benchmark.Manyargs(0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
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
}
});
benchmarks.put("Oneret", new Runnable() {
@Override public void run() {
Benchmark.Oneret();
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
}
});
final Benchmark.I javaRef = new AnI();
benchmarks.put("Refforeign", new Runnable() {
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
@Override public void run() {
Benchmark.Ref(javaRef);
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
}
});
final Benchmark.I goRef = Benchmark.NewI();
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
benchmarks.put("Refgo", new Runnable() {
@Override public void run() {
Benchmark.Ref(goRef);
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
}
});
benchmarks.put("StringShort", new Runnable() {
@Override public void run() {
Benchmark.String(Benchmark.ShortString);
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
}
});
benchmarks.put("StringLong", new Runnable() {
@Override public void run() {
Benchmark.String(Benchmark.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
}
});
benchmarks.put("StringShortUnicode", new Runnable() {
@Override public void run() {
Benchmark.String(Benchmark.ShortStringUnicode);
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
}
});
benchmarks.put("StringLongUnicode", new Runnable() {
@Override public void run() {
Benchmark.String(Benchmark.LongStringUnicode);
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
}
});
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
benchmarks.put("StringRetShort", new Runnable() {
@Override public void run() {
Benchmark.StringRetShort();
}
});
benchmarks.put("StringRetLong", new Runnable() {
@Override public void run() {
Benchmark.StringRetLong();
}
});
final byte[] shortSlice = Benchmark.getShortSlice();
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
benchmarks.put("SliceShort", new Runnable() {
@Override public void run() {
Benchmark.Slice(shortSlice);
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
}
});
final byte[] longSlice = Benchmark.getLongSlice();
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
benchmarks.put("SliceLong", new Runnable() {
@Override public void run() {
Benchmark.Slice(longSlice);
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
}
});
}
public void RunDirect(String name, final long n) {
final Runnable r = benchmarks.get(name);
try {
executor.submit(new Runnable() {
@Override public void run() {
for (int i = 0; i < n; i++) {
r.run();
}
}
}).get();
} catch (Exception e) {
throw new RuntimeException(e);
}
}
public void Run(String name, long n) {
final Runnable r = benchmarks.get(name);
for (int i = 0; i < n; i++) {
r.run();
}
}
@Override public Benchmark.I NewI() {
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
return new AnI();
}
@Override public void Ref(Benchmark.I i) {
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
}
@Override public void Noargs() {
}
@Override public void Onearg(long i) {
}
@Override public long Oneret() {
return 0;
}
@Override public void Manyargs(long p0, long p1, long p2, long p3, long p4, long p5, long p6, long p7, long gp8, long p9) {
}
@Override public void String(String s) {
}
@Override public void Slice(byte[] s) {
}
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
@Override public String StringRetShort() {
return Benchmark.ShortString;
}
@Override public String StringRetLong() {
return Benchmark.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
}
public void testBenchmark() {
Benchmark.RunBenchmarks(new Benchmarks());
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
}
}