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 13:55:00 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1606211350470.22630@virtualbox> (raw)
In-Reply-To: <F67587B5-0EA8-4F2F-AADB-4343B4FEEA21@gmail.com>

Hi Lars,

On Tue, 21 Jun 2016, Lars Schneider wrote:

> > On 20 Jun 2016, at 21:48, Junio C Hamano <gitster@pobox.com> wrote:
> > 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> >> On Sun, 19 Jun 2016, Lars Schneider wrote:
> >> 
> >>>> On 18 Jun 2016, at 15:03, Johannes Schindelin
> >>>> <johannes.schindelin@gmx.de> wrote:
> >>>> 
> >>>> As this developer has no access to MacOSX developer setups anymore,
> >>>> Travis becomes the best bet to run performance tests on that OS.
> >>> 
> >>> We don't run the performance tests on Travis CI right now.
> >>> Maybe we should? With your patch below it should work, right?
> >> ...
> >> 
> >> Yeah, well, I should have been clearer in my commit message: this patch
> >> allows the perf tests to *run*, not to *pass*... ;-)
> > 
> > OK, Lars, do we still want to take this patch?  I am leaning towards
> > taking it, if only to motivate interested others with OS X to look
> > into making the perf tests to actually run.
> 
> I think we definitively should take the "perf-lib.sh" part of the patch
> as this makes the perf test run on OSX and therefore is a strict
> improvement.

Yes, it was meant as the starting point to get more things to run on
MacOSX.

> 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?

> 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.

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.

Ciao,
Dscho

  reply	other threads:[~2016-06-21 11:57 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 [this message]
2016-06-21 12:49           ` Lars Schneider
2016-06-21 13:50             ` Johannes Schindelin
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.1606211350470.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.