I think this module was specifically added for running JMH benchmarks since it's pulling in the JMH plugin. JMH is framework for easily writing microbenchmarks.
I think it makes sense to put JMH benchmarks in the same package as the code under tests, since you may end up writing a microbenchmark for just one in internal class. Arguably, all of the modules could pull in the JMH plugin and these benchmarks could sit in those modules. I think the current structure might have just been the easiest way to integrate JMH into the build. -Dan On Sun, Jan 7, 2018 at 9:59 PM, Xiaojian Zhou <gz...@pivotal.io> wrote: > The package might be always a problem. Even you put the cq benchmark code > under geode-cq to near its source code, it might still have to access code > under other package, such as geode-core. > > So I think put benchmark test code under benchmark package is ok. Your > option 2) is good. > > Regards > Gester > > On Fri, Jan 5, 2018 at 11:57 AM, Nick Reich <nre...@pivotal.io> wrote: > > > Team, > > > > I am in the progress of adding new benchmarks to the (currently sparse) > > geode-benchmarks module. The lack of current examples in the module leads > > me to wonder what the correct organization of benchmarks in the module is > > (and if this is the right location). > > > > The existing benchmarks are all in org.apache.geode.cache.benchmark. > > Following this pattern would (presumably) result in benchmark subpackages > > in each package that has benchmarks. Making the root package > > org.apache.geode.benchmark would remove this proliferation of sub > packages. > > However, both these approaches have the issue that package level > > methods/classes cannot be accessed from benchmarks as they will never > share > > a package with the production code. > > > > 1) Should benchmarks then not be put in special benchmark packages? > > > > 2) Should our benchmarks not invoke package level methods/classes in the > > case that we should use benchmark packages? Or should such benchmarks not > > reside in the benchmarks module? > > > > 3) Is geode-benchmarks where we intend all benchmarks, only certain > classes > > of benchmarks (all using jmh for example), or would we prefer embedding > > them in the modules where the code being benchmarked resides? > > > > Thanks for your input. > > >
