[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What's your favourite *under_publicized* editing feature of Emacs?

From: Oleksandr Gavenko
Subject: Re: What's your favourite *under_publicized* editing feature of Emacs?
Date: Wed, 09 Feb 2011 22:51:37 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/20101027 Thunderbird/3.1.6

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.


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/" -*-
win-gui-admin.c:140: WndProc #8
win-gui-admin.c:140: WndProc #8
...  (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)
       (140 #1)))
 2 nil)

I assume that 'compilation-error-properties' spend time on setting this

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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]