#130: Support benchmarks having @State annotations in parent classes

[07jasjeet]

Targets #130

Changelog

1. Whenever a parent of a child class is directly or indirectly annotated with @State annotation, our child class will also be considered when generating benchmarks.
2. Supplimentary annotations like @Measurement @Warmup @OutputTime @BenchmarkMode are considered in this order: child -> top most annotated parent

Note: This is a phase-1 implementation, with just the basic idea laid out.

[qurbonzoda]

It seems to me that directlyAnnotatedInheritableClassDescriptors includes more than just abstract classes.

[07jasjeet]

Oops yes old comment. Will fix!

[qurbonzoda]

WDYT about using "non-final" instead of "inheritable"?
The term "non-final" just sounds more familiar to me.

[07jasjeet]

Sounds good.

[qurbonzoda]

Could directlyAnnotatedInheritableClassDescriptors be used here?
I am struggling to understand the need for annotatedInheritableClassDescriptors. Cloud you please clarify?

[07jasjeet]

Huh after another thought, I think directlyAnnotatedInheritableClassDescriptors should be used here. Will do!

[qurbonzoda]

Can find be used to simplify the code?

[qurbonzoda]

Could you please add some integration tests instead?

[qurbonzoda]

Could it be that there are multiple superclasses for this class descriptor?

[07jasjeet]

I was expecting this! So as for phase-1 I was just looking out for bare bones implementation which means this here just a base setup. Currently this function picks the first superclass that is directly annotated. Now there are some cases:

1. Simple straight forward: Only one annotated superclass.
2. Multiple superclasses but only one is annotated.
3. Multiple superclasses and intermediaries (super class of this but sub class of the top most annotated parent class) are annotated as well.
4. Multiple superclasses and intermediaries with annotations E.x., @Warmup, @Measurement etc without @State.

What should be the route to follow here?
For 4th point, my suggestion is that independent annotations should be ignored. For the 3rd point, I would suggest nearest annotated parent. 1st and 2nd are easily dealt with.

[qurbonzoda]

What should be the route to follow here?

It depends on how JMH handles this aspect. Being consistent with that library is important, since it runs the benchmarks on the JVM. Achieving consistent behavior across other platforms would be ideal. It is worth mentioning that we do not aim to replicate all of JMH's sophistication, but when something is not supported in non-JVM targets, we would like to issue a warning (or throw an exception) about it.

[qurbonzoda]

I would greatly appreciate it if you could check how JMH handles this case. It would greatly help us decide which route we should take.

[qurbonzoda]

Can the base class declare benchmark methods as well?

[07jasjeet]

No. As to why? -> It doesn't make sense to run the same benchmark again if two or more classes are inheriting from same non-final class.

[qurbonzoda]

I can think of the following use case:

import kotlinx.benchmark.*

@State(Scope.Benchmark)
@Measurement(iterations = 7, time = 1, timeUnit = BenchmarkTimeUnit.SECONDS)
@Warmup(iterations = 7, time = 1, timeUnit = BenchmarkTimeUnit.SECONDS)
@OutputTimeUnit(BenchmarkTimeUnit.MILLISECONDS)
abstract class IterationBenchmarkBase {
    abstract val list: List<String>

    @Param("10", "100")
    var size: Int = 0

    @Benchmark
    fun iterationBenchmark(bh: Blackhole) {
        for (element in list) {
            bh.consume(element)
        }
    }
}

class ArrayListIterationBenchmark : IterationBenchmarkBase() {
    override val list: List<String>
        get() = ArrayList<String>(size).apply { fill(size) }
}

class ArrayDequeIterationBenchmark : IterationBenchmarkBase() {
    override val list: List<String>
        get() = ArrayDeque<String>(size).apply { fill(size) }
}

private fun MutableList<String>.fill(size: Int) {
    addAll((1..size).map { it.toString() })
}

[qurbonzoda]

Can a TestInheritedBenchmark subclass declare benchmark methods as well?

[07jasjeet]

Could you expand a bit on your question?

[qurbonzoda]

I am referring to cases of multi-hierarchy benchmark classes, within which multiple classes define benchmark methods.

[qurbonzoda]

Note: This is a phase-1 implementation, with just the basic idea laid out.

I would appreciate it if you could clarify what exactly you think should be included in phase 1.