From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] perf: accommodate for MacOSX
Date: Tue, 21 Jun 2016 15:50:15 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1606211548230.22630@virtualbox> (raw)
In-Reply-To: <CD0404AE-529B-44B7-AE05-022D3062E596@gmail.com>
Hi Lars,
On Tue, 21 Jun 2016, Lars Schneider wrote:
> > On 21 Jun 2016, at 13:55, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
next prev parent reply other threads:[~2016-06-21 13:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-18 13:03 [PATCH] perf: accommodate for MacOSX Johannes Schindelin
2016-06-19 16:56 ` Lars Schneider
2016-06-20 6:45 ` Johannes Schindelin
2016-06-20 19:48 ` Junio C Hamano
2016-06-21 7:57 ` Lars Schneider
2016-06-21 11:55 ` Johannes Schindelin
2016-06-21 12:49 ` Lars Schneider
2016-06-21 13:50 ` Johannes Schindelin [this message]
2016-06-21 13:53 ` [PATCH v2] " Johannes Schindelin
2016-06-21 18:03 ` Lars Schneider
2016-06-21 18:35 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1606211548230.22630@virtualbox \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.