From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: slow output in *compilation* buffer Date: Tue, 25 Aug 2009 13:21:43 -0400 Message-ID: References: <200908220823.n7M8NAk5028199@godzilla.ics.uci.edu> <200908230627.n7N6R8Ph008721@godzilla.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251220933 1512 80.91.229.12 (25 Aug 2009 17:22:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2009 17:22:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 25 19:22:06 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MfziX-00025P-Bo for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 19:21:57 +0200 Original-Received: from localhost ([127.0.0.1]:47340 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfziW-0001mp-Nw for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 13:21:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MfziR-0001mQ-L9 for emacs-devel@gnu.org; Tue, 25 Aug 2009 13:21:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MfziN-0001lu-3o for emacs-devel@gnu.org; Tue, 25 Aug 2009 13:21:51 -0400 Original-Received: from [199.232.76.173] (port=57916 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MfziM-0001lr-UB for emacs-devel@gnu.org; Tue, 25 Aug 2009 13:21:46 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46984) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MfziM-0007kz-Hj for emacs-devel@gnu.org; Tue, 25 Aug 2009 13:21:46 -0400 Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n7PHLidF024356; Tue, 25 Aug 2009 13:21:44 -0400 Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 0D05E3A06B; Tue, 25 Aug 2009 13:21:44 -0400 (EDT) In-Reply-To: <200908230627.n7N6R8Ph008721@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Sat, 22 Aug 2009 23:27:08 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3348=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114590 Archived-At: >> - the re_* part of the profile is hard to improve with a quick fix, >> I think: it just represents regexp-searching every one of the regexps >> in compilation-error-regexp-alist in turn. Of course, there is a way >> to do that (a lot) faster, by compiling all those regexps into a DFA. > That sounds like a good idea, but it does not look like it will have a > huge impact? No, indeed, luckily. >> - why does the gprof data only seem to account for a bit less than 10s >> when you say it takes 25s to complete? > Don't know. I double checked and it's consistent. Maybe oprofile can > reveal more, I might try that too when I get a chance if nobody beats > me to it. Maybe it's just the user-time vs system-time. >> - It seems that they the calls to the interval code come from >> compilation-error-properties, but that function should only be called >> for regexps that do match, which shouldn't be that many. Can you look >> at the text to see if there really are that many matches? BTW, we >> should probably be able to make compile.el a bit lazier (i.e. the >> font-lock-phase part of the code should do a bit less work by moving >> it to the next-error-phase code). > The output is about 4500 lines, they all match. Ah, I see. So yes, the likely solution is to make compile.el lazier: use font-lock-syntactic-keywords and jit-lock (so the text past the end of the window doesn't need to be scanned right away), and postpone more of the work to next-error. > BTW, doing the same search with M-x rgrep is MUCH MUCH slower. That sucks. What does rgrep do so differently to make it even worse? > They time spent there seems a bit excessive, so maybe something strange > is going on... That's also possible. Stefan