That makes sense for some benchmarks but not others. For example, while working on the Logging changes, I wrote a some benchmarks that directly use some new internal code to ensure that the new changes perform well.
+1 to creating a benchmarks repo that has general perf tests that will be run in the pipelines -1 to getting rid of benchmarks from geode-core or any other submodule because this will discourage developers from writing benchmarks specific to new code as they write it -- we shouldn't be forced to write benchmarks AFTER we commit to the main geode repo (or worse, after a release) On Thu, Nov 15, 2018 at 10:47 AM Dan Smith <dsm...@pivotal.io> wrote: > Hi all, > > We (Naba, Sean, Brian and I) would like to add some benchmarks for geode, > with a goal of eventually running them as part of our concourse build and > detecting performance changes. > > We think it makes sense to put these benchmarks in a separate > geode-benchmarks repository. That will make them less tightly coupled to a > specific revision of geode. What do you all think? If folks are okay with > this, I will go ahead and create the repository. > > We have some prototype code in this repository with a simple client/server > put benchmark: https://github.com/upthewaterspout/geode-performance. > > -Dan >
