Add fast-path for no-args constructor in BeanUtils.instantiateClass

[stsypanov]

For the cases when constructor has no args we could have fast-paths which is likely to improve start-up time as BeanUtils.instantiateClass is called at least once for each bean instantiation in application context.

[stsypanov]

@sdeleuze Could you have a look into this?

[sdeleuze]

I would like to have data points for Kotlin and Java via JMH to be able to decide if we integrate such change or not, could you please measure that and share the results?

[sdeleuze]

Given the fact that JetBrains/kotlin#2855 has been closed because in practice it brings no benefit, is that part still relevant from your POV and if yes, could you elaborate on why and provide a JMH benchmark to quantify the gains?

[stsypanov]

Hi, here's the benchmark:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
open class MyBenchmark {
    private val noArgConstructor = TestClass1::class.java.getDeclaredConstructor()
    private val constructor = TestClass2::class.java.getDeclaredConstructor(Int::class.java, String::class.java)

    @Benchmark
    fun emptyConstructor(): Any {
        return BeanUtils.instantiateClass(noArgConstructor)
    }

    @Benchmark
    fun nonEmptyConstructor(): Any {
        return BeanUtils.instantiateClass(constructor, 1, "str")
    }

    class TestClass1()

    class TestClass2(int: Int, string: String)
}

Results:

before

Benchmark                                                         Mode  Cnt     Score    Error   Units
MyBenchmark.emptyConstructor                                      avgt  100    52,279 ?  1,089   ns/op
MyBenchmark.emptyConstructor:?gc.alloc.rate.norm                  avgt  100   140,815 ?  2,499    B/op
MyBenchmark.nonEmptyConstructor                                   avgt  100   272,787 ?  3,971   ns/op
MyBenchmark.nonEmptyConstructor:?gc.alloc.rate.norm               avgt  100   985,684 ?  4,364    B/op

after

Benchmark                                                         Mode  Cnt     Score    Error   Units
MyBenchmark.emptyConstructor                                      avgt  100    50,635 ?  0,870   ns/op
MyBenchmark.emptyConstructor:?gc.alloc.rate.norm                  avgt  100    91,853 ?  2,329    B/op
MyBenchmark.nonEmptyConstructor                                   avgt  100   265,335 ?  5,555   ns/op
MyBenchmark.nonEmptyConstructor:?gc.alloc.rate.norm               avgt  100   988,885 ?  3,272    B/op

[sdeleuze]

Could you please provide a JMH benchmark of the gains?

[stsypanov]

Yeah, I'll try to. The immediate gain here is that we don't allocate a new array calling ctor.getParameterTypes() for zero-arg constructor case

[sdeleuze]

I am still interested by concrete data points with JMH benchmarks before and after the proposed change, could you please provide that?

[stsypanov]

Here's the benchmark:

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
    private Constructor<TestClass1> noArgConstructor;
    private Constructor<TestClass2> constructor;

    @Setup
    public void setUp() throws NoSuchMethodException {
        noArgConstructor = TestClass1.class.getDeclaredConstructor();
        constructor = TestClass2.class.getDeclaredConstructor(int.class, String.class);
    }

    @Benchmark
    public Object emptyConstructor() {
        return BeanUtils.instantiateClass(noArgConstructor);
    }

    @Benchmark
    public Object nonEmptyConstructor() {
        return BeanUtils.instantiateClass(constructor, 1, "str");
    }

    static class TestClass1{
    };

    static class TestClass2 {
        private final int value1;
        private final String value2;

        TestClass2(int value1, String value2) {
            this.value1 = value1;
            this.value2 = value2;
        }
    }
}

And results:

baseline
Benchmark                                                         Mode  Cnt     Score     Error   Units
MyBenchmark.emptyConstructor                                      avgt   40     9,880 ±   0,630   ns/op
MyBenchmark.emptyConstructor:·gc.alloc.rate.norm                  avgt   40    32,003 ±   0,001    B/op
MyBenchmark.nonEmptyConstructor                                   avgt   40    11,937 ±   0,131   ns/op
MyBenchmark.nonEmptyConstructor:·gc.alloc.rate.norm               avgt   40    48,004 ±   0,001    B/op

patched

Benchmark                                                         Mode  Cnt     Score    Error   Units
MyBenchmark.emptyConstructor                                      avgt   40     5,968 ±  0,112   ns/op
MyBenchmark.emptyConstructor:·gc.alloc.rate.norm                  avgt   40    16,002 ±  0,001    B/op
MyBenchmark.nonEmptyConstructor                                   avgt   40    11,922 ±  0,255   ns/op
MyBenchmark.nonEmptyConstructor:·gc.alloc.rate.norm               avgt   40    48,004 ±  0,001    B/op

[stsypanov]

@sdeleuze is there anything I could do about this PR?

[sdeleuze]

@stsypanov Thanks for your patience. I am ok with the Java changes, but the Kotlin ones break some tests and introduce too much duplication. I have refined the implementation with sdeleuze@9d8a035, which also makes it slightly faster (the branch is available here). Could you please provide me your feedback on those changes?