geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Smith <dsm...@pivotal.io>
Subject Re: [DISCUSS] Benchmarks module package structure
Date Mon, 08 Jan 2018 21:40:45 GMT
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 <gzhou@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 <nreich@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message