All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: git@vger.kernel.org
Cc: Jeff King <peff@peff.net>,
	Jacob Keller <jacob.e.keller@intel.com>,
	Jacob Keller <jacob.keller@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: [PATCH] coccicheck: process every source file at once
Date: Wed, 3 Oct 2018 17:05:22 +0200	[thread overview]
Message-ID: <20181003150522.GQ23446@localhost> (raw)
In-Reply-To: <20181003101658.GM23446@localhost>

On Wed, Oct 03, 2018 at 12:16:58PM +0200, SZEDER Gábor wrote:
> On Tue, Oct 02, 2018 at 03:55:19PM -0400, Jeff King wrote:
> > On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
> > 
> > > make coccicheck is used in order to apply coccinelle semantic patches,
> > > and see if any of the transformations found within contrib/coccinelle/
> > > can be applied to the current code base.
> > > 
> > > Pass every file to a single invocation of spatch, instead of running
> > > spatch once per source file.
> > > 
> > > This reduces the time required to run make coccicheck by a significant
> > > amount of time:
> > > 
> > > Prior timing of make coccicheck
> > >   real    6m14.090s
> > >   user    25m2.606s
> > >   sys     1m22.919s
> > > 
> > > New timing of make coccicheck
> > >   real    1m36.580s
> > >   user    7m55.933s
> > >   sys     0m18.219s
> > 
> > Yay! This is a nice result.
> > 
> > It's also one of the things that Julia suggested in an earlier thread.
> > One thing I wasn't quite sure about after digging into the various
> > versions (1.0.4 on Debian stable/unstable, 1.0.6 in experimental, and
> > pre-1.0.7 at the bleeding edge) was whether the old versions would be
> > similarly helped (or work at all).
> > 
> > I just replicated your results with 1.0.4.deb-3+b2 from Debian stable.
> > It's possible there are older versions floating around, but for
> > something developer-only like this, I think "in Debian stable" is a
> > reasonable enough cutoff.
> 
> Linux build jobs on Travis CI run Ubuntu Trusty 14.04 LTS, and
> therefore our static analysis build job still runs 1.0.0~rc19.deb-3.
> 
> This patch appears to work fine with that version, too,

In fact, it works finer than ever, because running 1.0.0 with this
patch on Travis CI notices a possible memmove() -> MOVE_ARRAY()
conversion:

  https://travis-ci.org/szeder/git/jobs/436542684#L576

Surprisingly, running 1.0.0 without this patch, or running 1.0.4
locally either with or without this patch doesn't notice that
memmove() call.  Presumably that's why Jonathan could kind-of "revert"
my conversion from f919ffebed (Use MOVE_ARRAY, 2018-01-22) in his
6a1a79fd14 (object: move grafts to object parser, 2018-05-15) without
anyone noticing.


  reply	other threads:[~2018-10-03 15:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 19:16 [PATCH] coccicheck: process every source file at once Jacob Keller
2018-10-02 19:55 ` Jeff King
2018-10-02 20:00   ` Jacob Keller
2018-10-02 20:31     ` Jeff King
2018-10-02 20:58       ` Jacob Keller
2018-10-02 21:08         ` Jeff King
2018-10-03 10:16   ` SZEDER Gábor
2018-10-03 15:05     ` SZEDER Gábor [this message]
2018-10-03 15:52       ` Jacob Keller
2018-10-03 17:54         ` Stefan Beller
2018-10-03 15:51     ` Jacob Keller

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=20181003150522.GQ23446@localhost \
    --to=szeder.dev@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jacob.keller@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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.