Ми працюємо над додатком, чутливим до затримок, і проводили мікробенчмаркінг усіх видів методів (використовуючи jmh ). Після мікробенчмаркінгу методу пошуку та задовольнившись результатами, я застосував остаточну версію, лише виявивши, що остаточна версія була в 3 рази повільнішою за ту, яку я щойно провів.
Виною тому, що реалізований метод повертав enumоб'єкт замість int. Ось спрощена версія базового коду:
@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReturnEnumObjectVersusPrimitiveBenchmark {
enum Category {
CATEGORY1,
CATEGORY2,
}
@Param( {"3", "2", "1" })
String value;
int param;
@Setup
public void setUp() {
param = Integer.parseInt(value);
}
@Benchmark
public int benchmarkReturnOrdinal() {
if (param < 2) {
return Category.CATEGORY1.ordinal();
}
return Category.CATEGORY2.ordinal();
}
@Benchmark
public Category benchmarkReturnReference() {
if (param < 2) {
return Category.CATEGORY1;
}
return Category.CATEGORY2;
}
public static void main(String[] args) throws RunnerException {
Options opt = new OptionsBuilder().include(ReturnEnumObjectVersusPrimitiveBenchmark.class.getName()).warmupIterations(5)
.measurementIterations(4).forks(1).build();
new Runner(opt).run();
}
}
Орієнтовні результати для вище:
# VM invoker: C:\Program Files\Java\jdk1.7.0_40\jre\bin\java.exe
# VM options: -Dfile.encoding=UTF-8
Benchmark (value) Mode Samples Score Error Units
benchmarkReturnOrdinal 3 thrpt 4 1059.898 ± 71.749 ops/us
benchmarkReturnOrdinal 2 thrpt 4 1051.122 ± 61.238 ops/us
benchmarkReturnOrdinal 1 thrpt 4 1064.067 ± 90.057 ops/us
benchmarkReturnReference 3 thrpt 4 353.197 ± 25.946 ops/us
benchmarkReturnReference 2 thrpt 4 350.902 ± 19.487 ops/us
benchmarkReturnReference 1 thrpt 4 339.578 ± 144.093 ops/us
Просто зміна типу повернення функції змінила продуктивність майже в 3 рази.
Я думав, що єдина різниця між поверненням об'єкта перерахування та цілим числом полягає в тому, що один повертає 64-бітове значення (посилання), а інший повертає 32-бітове значення. Один з моїх колег здогадувався, що повернення переліку додало додаткових накладних витрат через необхідність відстеження посилання на потенційний GC. (Але враховуючи те, що перелічені об’єкти є статичними кінцевими посиланнями, здається дивним, що це потрібно було б зробити).
Яке пояснення різниці в продуктивності?
ОНОВЛЕННЯ
Я поділився тут проектом maven, щоб кожен міг його клонувати та запустити еталон. Якщо хтось має час / інтерес, було б корисно подивитися, чи зможуть інші повторити ті самі результати. (Я тиражував на двох різних машинах, Windows 64 та Linux 64, обидва використовували версії JVM Oracle Java 1.7). @ZhekaKozlov каже, що не бачив різниці між методами.
Запустити: (після клонування сховища)
mvn clean install
java -jar .\target\microbenchmarks.jar function.ReturnEnumObjectVersusPrimitiveBenchmark -i 5 -wi 5 -f 1
.