All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.