Hi Lars, On Tue, 21 Jun 2016, Lars Schneider wrote: > > On 21 Jun 2016, at 13:55, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > > > >> ... > >> If we don't run any perf tests by default on Travis CI then I wouldn't > >> take the ".travis.yml" part of the patch just to keep our Travis CI > >> setup as lean as possible. > > > > Maybe commented-out, so that people like me have a chance to use Travis > > for MacOSX perf testing? > > > > Could you let me know whether a commented-out > > > > # Uncomment this if you want to run perf tests: > > # brew install gnu-time > > > > would be acceptable? I will reroll the patch accordingly. > > Commented-out would be fine with me! Okay! Updated patch coming in a moment. > >> Running perf tests on Travis CI is probably bogus anyways because we > >> never know on what hardware our jobs run and what other jobs run in > >> parallel on that hardware. > > > > While I agree that the absolute timings cannot be trusted, I have to point > > out that the relative timings on Linux at least are consistent with what I > > could test locally. > > Given that the relative timings are consistent for you. Maybe there is > value to run the performance tests (e.g. only on the master branch) > in a separate Travis job. Then we could chart the timings over releases. > I dunno. Sure, that would be a fine addition, if there is a way, somehow, to chart the timings (keep in mind that Travis runs for each and every iteration of each and every PR, in addition to the branch updates). I do have enough on my plate, though, so I will have to hope that somebody else picks this up. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html