Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754577AbZBAA6S (ORCPT ); Sat, 31 Jan 2009 19:58:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752729AbZBAA6F (ORCPT ); Sat, 31 Jan 2009 19:58:05 -0500 Received: from fifo99.com ([67.223.236.141]:47714 "EHLO fifo99.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752693AbZBAA6E (ORCPT ); Sat, 31 Jan 2009 19:58:04 -0500 Subject: Re: checkpatch.pl is getting too slow From: Daniel Walker To: Andy Whitcroft Cc: Greg KH , linux-kernel@vger.kernel.org In-Reply-To: <20090131210220.GA25811@shadowen.org> References: <20090131185507.GA3280@kroah.com> <20090131210220.GA25811@shadowen.org> Content-Type: text/plain Date: Sat, 31 Jan 2009 16:57:57 -0800 Message-Id: <1233449877.5903.48.camel@desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3041 Lines: 77 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 > > > > > > 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; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/