From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleksandr Gavenko Newsgroups: gmane.emacs.help Subject: Re: What's your favourite *under_publicized* editing feature of Emacs? Date: Wed, 09 Feb 2011 23:31:15 +0200 Message-ID: References: <4D4F0063.10708@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1297287130 20302 80.91.229.12 (9 Feb 2011 21:32:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 9 Feb 2011 21:32:10 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Feb 09 22:32:06 2011 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PnHdt-00067N-MM for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Feb 2011 22:32:05 +0100 Original-Received: from localhost ([127.0.0.1]:52994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnHdu-0006ba-Dv for geh-help-gnu-emacs@m.gmane.org; Wed, 09 Feb 2011 16:32:06 -0500 Original-Received: from [140.186.70.92] (port=45374 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PnHdT-0006az-3r for help-gnu-emacs@gnu.org; Wed, 09 Feb 2011 16:31:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PnHdQ-0007AR-HZ for help-gnu-emacs@gnu.org; Wed, 09 Feb 2011 16:31:37 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:45310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PnHdQ-00079z-4S for help-gnu-emacs@gnu.org; Wed, 09 Feb 2011 16:31:36 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PnHdO-0005iW-Aj for help-gnu-emacs@gnu.org; Wed, 09 Feb 2011 22:31:34 +0100 Original-Received: from 94-248-56-161.dynamic.peoplenet.ua ([94.248.56.161]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Feb 2011 22:31:34 +0100 Original-Received: from gavenkoa by 94-248-56-161.dynamic.peoplenet.ua with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 09 Feb 2011 22:31:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 121 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 94-248-56-161.dynamic.peoplenet.ua User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:79053 Archived-At: On 2011-02-09 6:37, Stefan Monnier wrote: >>> I set 'grep-mode' on my log file (which follow GNU >>> error coding convention). On 50-100 KiB logs it take >>> 10 sec to highlight matches. On larger files I type >>> C-g to stop matching for highlighting. > > You may want to try the Emacs trunk's version of compile.el (I think > it'll work with Emacs-23 as well). It should help out by being more > lazy (e.g. it'll still takes 10s to parse the file when you jump to the > end of it, but it should open instantaneously because it'll only need to > parse the first page for that). > Sound interesting. But you wrote that jumping to end of buffer take whole time (( We recently discuss about Emacs hex mode and I ask how read only needed part of file to display (as binaries some times very large for opening in Emacs). This allow Emacs spend time on processing only needed (displayed) part of information. Same with highlighting of compilation/grep like buffers. Usually reference for file/line placed on single line (or two...). So highlighting can be performed only on visible part on large files. Does currently Emacs highlight all file or this depend on mode? How about generic-modes? >> And I realize that compilation-mode is dumb as it try >> set on all matched file/line pairs text properties to >> allow move to another file by RET. > > compilation-mode indeed does more work than I'd like at the "highlight" > time, and some of that work could indeed be delayed to the moment the > user hits RET on a line. But my impression is that most of the time is > spent regexp-matching (i.e. looking for matches) anyway, so moving this > work won't make much difference if any. IOW my impression is that if > your code is faster it's because it uses either more efficient regexps, > or fewer regexps. > >> ("^\\([^:]+\\):\\([[:digit:]]+\\):[^ > > E.g. this regexp is more efficient than the one used by grep.el, by > disallowing : in file names (resulting in a backtrack-free regexp). > I previously ask about regex performance in this list and try define-generic-mode with different regex. Time to highlighting do not significant changed with different regex. Seems problem in another place and I read doc how profile. Look at 'my.log' file, which is 289 KiB long: -*- mode: my-log; default-directory: "~/devel/job/plugin-hg/" -*- WM: 0x0024: WM_GETMINMAXINFO win-gui-admin.c:140: WndProc #8 WM: 0x0024: WM_GETMINMAXINFO win-gui-admin.c:140: WndProc #8 WM: 0x0024: WM_GETMINMAXINFO ... (repeat 2 last lines many times) When I eval: (benchmark-run 1 (revert-buffer)) I get: (0.172 0 0.0) When I change mode line to -*- mode: grep; default-directory: "~/devel/job/plugin-hg/" -*- and eval: (benchmark-run 1 (revert-buffer)) I get: (22.406 1 0.156) As you can see it is 100 times slower! I perform 'M-x elp-instrument-package grep' and 'M-x elp-instrument-package compilation'. Next I perform '(revert-buffer)' and 'M-x elp-results' and get: grep-mode 1 23.906 23.906 compilation-error-properties 4742 23.047 0.0048601855 compilation-internal-error-properties 4742 0.094 1.98...e-005 compilation-get-file-structure 4742 0.016 3.37...e-006 compilation-mode 1 0.0 0.0 compilation-mode-font-lock-keywords 1 0.0 0.0 compilation-setup 1 0.0 0.0 As you can see 'compilation-error-properties' eat a lot of time and it executed on all lines like 'file:line: msg' (in my example half of lines match such pattern)! I press C-u C-x = on green underscored char (file name for jump) and see among text properties: 'message' with value is: ((nil 140 (("win-gui-admin.c" nil) nil (140 #1))) 2 nil) I assume that 'compilation-error-properties' spend time on setting this properties. So because of unnecessary work to set text property to well structured data on *all* lines we have slow down instead perform parsing of reference on demand. As I previously shown 'my-log-goto' func for this purpose. I think such idea (trying match pattern on point position) can be generalized by looping across 'compilation-error-regexp-alist'. Do you think this need filed as a bug or request? Or I am something missing? -- Best regards!