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.
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).