+1 for adding src/jmh/java to each module. I submitted a PR with that
change and a new benchmark in geode-core last year, but I ended up closing
it after a couple months. If anyone wants help, let me know.
On Mon, Jan 8, 2018 at 3:23 PM, Nick Reich wrote:
> I think if we can make it work, removi
I think if we can make it work, removing the benchmarks module and moving
the benchmarks into the module where the code they are testing resides
would be the ideal. Talking with Dan, this would result in a src/jmh/java
source directory in any module with benchmarks, which I think would result
in a
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 wrote:
> I think this module was specifically added for running JMH benchmarks since
> it's
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 f
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
O
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
