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

[Oleksandr Gavenko]

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!