public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Walker <dwalker@fifo99.com>
To: Andy Whitcroft <apw@canonical.com>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: checkpatch.pl is getting too slow
Date: Sat, 31 Jan 2009 16:57:57 -0800	[thread overview]
Message-ID: <1233449877.5903.48.camel@desktop> (raw)
In-Reply-To: <20090131210220.GA25811@shadowen.org>

On Sat, 2009-01-31 at 21:02 +0000, Andy Whitcroft wrote:
> On Sat, Jan 31, 2009 at 10:55:07AM -0800, Greg KH wrote:
> > Hi Andy,
> > 
> > I've noticed that checkpatch.pl is getting slower and slower when run on
> > a whole file, but yesterday I realized that it now is pretty much
> > unusable:
> > 
> > $ time ./scripts/checkpatch.pl --file drivers/staging/uc2322/aten2011.c
> > 
> > <snip>
> > total: 168 errors, 126 warnings, 3939 lines checked
> > 
> > drivers/staging/uc2322/aten2011.c has style problems, please review.  If any of these errors
> > are false positives report them to the maintainer, see
> > CHECKPATCH in MAINTAINERS.
> > 
> > real	8m7.924s
> > user	8m7.058s
> > sys	0m0.116s
> 
> That is scarey indeed.  Something is very wrong in there if it went back
> to a more reasonable 10's of seconds with a few patches.  I will have a
> look at the file you attached and see what I can find.
> 
> Thanks for the heads up.

After some debugging it looks like it takes a long time to processes
lines similar to,

/*************************************
 * Bit definitions for each register *
 *************************************/
#define LCR_BITS_5              0x00    /* 5 bits/char */
#define LCR_BITS_6              0x01    /* 6 bits/char */
#define LCR_BITS_7              0x02    /* 7 bits/char */
#define LCR_BITS_8              0x03    /* 8 bits/char */
#define LCR_BITS_MASK           0x03    /* Mask for bits/char field */


There's a section in the code which has several of these. The processing
slows down when this expression matches repeatedly,

# Check for potential 'bare' types
                my ($stat, $cond, $line_nr_next, $remain_next, $off_next);
                if ($realcnt && $line =~ /.\s*\S/) {
                        ($stat, $cond, $line_nr_next, $remain_next, $off_next) =
                                ctx_statement_block($linenr, $realcnt, 0);

and ctx_statement_block will process $realcnt lines trying to find a
complete block, and it has no concept of "define" so it just keep
processing until it's concept of a block ending.. That happens on each
"define" line in the file, which I think accounts for all the overhead.

I added the following temporary work around, which speeds things up
considerably. Just forcing it to only process one line at most.

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 45eb0ae..787423a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1357,7 +1357,7 @@ sub process {
 		my ($stat, $cond, $line_nr_next, $remain_next, $off_next);
 		if ($realcnt && $line =~ /.\s*\S/) {
 			($stat, $cond, $line_nr_next, $remain_next, $off_next) =
-				ctx_statement_block($linenr, $realcnt, 0);
+				ctx_statement_block($linenr, 1, 0);
 			$stat =~ s/\n./\n /g;
 			$cond =~ s/\n./\n /g;
 



  parent reply	other threads:[~2009-02-01  0:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-31 18:55 checkpatch.pl is getting too slow Greg KH
2009-01-31 21:02 ` Andy Whitcroft
2009-01-31 21:35   ` Daniel Walker
2009-01-31 22:10     ` Daniel Walker
2009-02-01  0:57   ` Daniel Walker [this message]
2009-02-01  4:46     ` Greg KH
2009-02-01 14:33       ` Daniel Walker
2009-02-01 17:47       ` Daniel Walker
2009-02-03  5:16         ` Greg KH
2009-02-09  8:41           ` Andy Whitcroft
2009-02-09  8:58         ` Andy Whitcroft

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=1233449877.5903.48.camel@desktop \
    --to=dwalker@fifo99.com \
    --cc=apw@canonical.com \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    /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