We'll probably end up writing benchmarks for classes or methods that are package-private, so that would be one reason to not create a special benchmarks package.
On Mon, Jan 8, 2018 at 1:40 PM, Dan Smith <dsm...@pivotal.io> wrote: > 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. > > > > > >
