From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: slow output in *compilation* buffer Date: Wed, 26 Aug 2009 00:33:08 -0700 (PDT) Message-ID: <200908260733.n7Q7X8Qh018681@godzilla.ics.uci.edu> 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 1251273653 4769 80.91.229.12 (26 Aug 2009 08:00:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 08:00:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 10:00:42 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 1MgDQv-0001E4-Oh for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 10:00:42 +0200 Original-Received: from localhost ([127.0.0.1]:42890 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgDQv-0007JB-9e for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 04:00:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgD2v-0004ug-KT for emacs-devel@gnu.org; Wed, 26 Aug 2009 03:35:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgD2r-0004sl-NN for emacs-devel@gnu.org; Wed, 26 Aug 2009 03:35:53 -0400 Original-Received: from [199.232.76.173] (port=57837 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgD2r-0004sh-L1 for emacs-devel@gnu.org; Wed, 26 Aug 2009 03:35:49 -0400 Original-Received: from mx20.gnu.org ([199.232.41.8]:5438) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MgD2r-0005br-0L for emacs-devel@gnu.org; Wed, 26 Aug 2009 03:35:49 -0400 Original-Received: from sallyv2.ics.uci.edu ([128.195.1.120]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgD1O-0001eO-7E for emacs-devel@gnu.org; Wed, 26 Aug 2009 03:34:18 -0400 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by sallyv2.ics.uci.edu (8.13.8+Sun/8.13.8) with ESMTP id n7Q7X91E002404; Wed, 26 Aug 2009 00:33:09 -0700 (PDT) Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id n7Q7X8Qh018681; Wed, 26 Aug 2009 00:33:08 -0700 (PDT) Original-Lines: 58 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: n7Q7X91E002404 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu X-Detected-Operating-System: by mx20.gnu.org: Solaris 10 (beta) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:114609 Archived-At: Stefan Monnier writes: > >> - 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. elp says that most time is spent in `compilation-error-properties', if that helps... > > 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. > > > They time spent there seems a bit excessive, so maybe something strange > > is going on... > > That's also possible. % cumulative self self total time seconds seconds calls s/call s/call name 33.02 2.46 2.46 50974295 0.00 0.00 lookup_char_property 21.61 4.07 1.61 50847996 0.00 0.00 previous_interval 13.83 5.10 1.03 204112526 0.00 0.00 Fcdr 7.25 5.64 0.54 50946735 0.00 0.00 Fassq 6.17 6.10 0.46 4509 0.00 0.00 Fprevious_single_property_change elp says there are 9018 calls to `compilation-error-properties' The file has 4509 lines, and it's fontified twice (M-x compilation-mode + M-x font-lock-fontify-buffer) That means 50974295/4509 = 11305 lookup_char_property calls per Fprevious_single_property_change ... that sounds a bit excessive. Now lets just double the input file (cat input input > input2) and perform the same experiment on the new file. % cumulative self self total time seconds seconds calls s/call s/call name 37.86 12.09 12.09 203594871 0.00 0.00 lookup_char_property 21.20 18.86 6.77 203351394 0.00 0.00 previous_interval 17.38 24.41 5.55 814793814 0.00 0.00 Fcdr 5.98 26.32 1.91 9018 0.00 0.00 Fprevious_single_property_change 203594871/9018 = 22576