From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: slow output in *compilation* buffer Date: Tue, 25 Aug 2009 23:37:34 +0200 Organization: Organization?!? Message-ID: <87prajlgm9.fsf@lola.goethe.zz> 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 1251236312 19294 80.91.229.12 (25 Aug 2009 21:38:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Aug 2009 21:38:32 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 25 23:38:25 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 1Mg3ij-0000Ad-Dg for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 23:38:25 +0200 Original-Received: from localhost ([127.0.0.1]:37684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mg3ii-00008n-Ob for ged-emacs-devel@m.gmane.org; Tue, 25 Aug 2009 17:38:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mg3iS-0008MI-9j for emacs-devel@gnu.org; Tue, 25 Aug 2009 17:38:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mg3iM-0008Hg-0C for emacs-devel@gnu.org; Tue, 25 Aug 2009 17:38:06 -0400 Original-Received: from [199.232.76.173] (port=50012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mg3iL-0008HR-Jf for emacs-devel@gnu.org; Tue, 25 Aug 2009 17:38:01 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:40905) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mg3iK-0005XH-Rz for emacs-devel@gnu.org; Tue, 25 Aug 2009 17:38:01 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1Mg3iH-0008Rw-AY for emacs-devel@gnu.org; Tue, 25 Aug 2009 23:37:57 +0200 Original-Received: from p5b2c37df.dip.t-dialin.net ([91.44.55.223]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Aug 2009 23:37:57 +0200 Original-Received: from dak by p5b2c37df.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Aug 2009 23:37:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 51 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c37df.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:6vza5RTc+oOs6yB8wM9iO1lX3oE= 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:114597 Archived-At: Stefan Monnier writes: >>> - 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. Does (setq process-adaptive-read-buffering nil) make a difference? I have the suspicion that this still exhibits pathological behavior sometimes. -- David Kastrup