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: Wed, 26 Aug 2009 14:56:44 -0400 Message-ID: References: <200908220823.n7M8NAk5028199@godzilla.ics.uci.edu> <200908230627.n7N6R8Ph008721@godzilla.ics.uci.edu> <200908260733.n7Q7X8Qh018681@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 1251315230 14203 80.91.229.12 (26 Aug 2009 19:33:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 19:33:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 21:33:43 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 1MgOFa-0004Ry-N6 for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 21:33:43 +0200 Original-Received: from localhost ([127.0.0.1]:49976 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgOFa-00031e-2M for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 15:33:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgNfw-00010z-Bm for emacs-devel@gnu.org; Wed, 26 Aug 2009 14:56:52 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgNfr-0000ri-FY for emacs-devel@gnu.org; Wed, 26 Aug 2009 14:56:51 -0400 Original-Received: from [199.232.76.173] (port=41655 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgNfq-0000r3-Rg for emacs-devel@gnu.org; Wed, 26 Aug 2009 14:56:46 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:64801 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgNfq-0002hp-El for emacs-devel@gnu.org; Wed, 26 Aug 2009 14:56:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4EAFsilUpFpYuS/2dsb2JhbACBU9dfhBoFh2OCaw X-IronPort-AV: E=Sophos;i="4.44,281,1249272000"; d="scan'208";a="44245855" Original-Received: from 69-165-139-146.dsl.teksavvy.com (HELO ceviche.home) ([69.165.139.146]) by ironport2-out.teksavvy.com with ESMTP; 26 Aug 2009 14:55:51 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0B778B40F3; Wed, 26 Aug 2009 14:56:44 -0400 (EDT) In-Reply-To: <200908260733.n7Q7X8Qh018681@godzilla.ics.uci.edu> (Dan Nicolaescu's message of "Wed, 26 Aug 2009 00:33:08 -0700 (PDT)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:114626 Archived-At: >> 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. > elp says that most time is spent in `compilation-error-properties', if > that helps... Yes. We should remove the call to previous-single-property-change from that function and move it to next-error instead. After all, the property we look for is almost never used, so this previous-single-property-change takes time O(N) where N is the amount of output that has already been received. So overall, it causes an O(N^2) behavior since it is called O(N) times. >> > 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? > My guess would be more highlighting: it also highlights the matched > words on each line. That's possible, but I'd expect there's something more at play here. > That means 50974295/4509 = 11305 lookup_char_property calls per Fprevious_single_property_change ... > that sounds a bit excessive. Since lookup_char_property will be called for each interval (i.e. chunk of text with the same text-properties) between point and the previous position where the property of interest is changed (which will usually be (point-min) in our case), I think it's about right (let's see: 4500 lines, each line has at least 3-4 chunks with different properties, for a total of about 20000 chunks, so about 10000 scanned per call on average). Stefan