bug#17837: 24.4.50; Search very slow

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

Visit stallman.org/archives/2014-mar-jun.html and type `C-s
interview'.  It takes a long time.  Repeat with C-s a few times; each
time, it takes a long time.

Disable Font Lock mode, and it becomes nice and fast.

I get the impression that searching fontifies all the text
it moves through.  Is that really necessary?  It is a big pain in the neck.




In GNU Emacs 24.4.50.3 (mips64el-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2014-06-02 on chiefs-gnewsense
Repository revision: 117230 michael.albinus@gmx.de-20140602113540-62kmuoznodmv94kd
System Description:	gNewSense GNU/Linux 3.0 (parkes)

Configured using:
 `configure 'CFLAGS=-O0 -g''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GCONF NOTIFY LIBSELINUX
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: RMAIL

Minor modes in effect:
  diff-auto-refine-mode: t
  shell-dirtrack-mode: t
  gpm-mouse-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
R TAB RET C-a C-p C-p C-@ C-n C-n C-n ESC w C-x b R 
TAB RET C-x b c a l l s RET C-s m o g l e n C-a C-n 
C-o C-o SPC SPC L a SPC a b o u t C-a ESC f w C-e SPC 
: r e a l ESC b DEL " C-e SPC n a m e " . C-x C-s C-x 
b RET C-@ C-p C-p C-p r ESC , RET D o e s SPC C-a C-k 
C-o T h a t SPC a r t i c l e SPC t a o k DEL DEL l 
k s SPC a b o u t SPC u s i n g SPC G o o g l e + . 
RET I f SPC y o u SPC m a k e SPC a SPC g DEL G o o 
g l e SPC a c c t SPC a n d SPC d o n ' t SPC u s e 
SPC G o o g l e + C-a ESC f ESC f ESC f ESC f ESC f 
ESC f SPC f o r SPC l o a d i n g SPC a p p s C-e , 
RET d o e s SPC G o o g l e SPC s t i l l SPC r e q 
u i r e SPC y o u r SPC r e a l SPC n a m e ? ESC ; 
C-c C-c ESC < C-x 1 d u o g o o g l e . x TAB RET d 
d x ESC x r e p o r t SPC e m a c s SPC b u g RET

Recent messages:
Saving file /home/rms/calls...
Wrote /home/rms/calls
Mark set [2 times]
Auto-saving...done
Mark set
Sending...
Wrote /home/rms/outgoing/out-6
Sending...done
Added to /home/rms/xmail/google.xmail
Expunging deleted messages...done

Load-path shadows:
/home/rms/emacs-bzr/trunk/lisp/leim/quail/lao hides /home/rms/emacs-bzr/trunk/lisp/language/lao
/home/rms/emacs-bzr/trunk/lisp/leim/quail/georgian hides /home/rms/emacs-bzr/trunk/lisp/language/georgian
/home/rms/emacs-bzr/trunk/lisp/leim/quail/thai hides /home/rms/emacs-bzr/trunk/lisp/language/thai
/home/rms/emacs-bzr/trunk/lisp/leim/quail/ethiopic hides /home/rms/emacs-bzr/trunk/lisp/language/ethiopic
/home/rms/emacs-bzr/trunk/lisp/leim/quail/japanese hides /home/rms/emacs-bzr/trunk/lisp/language/japanese
/home/rms/emacs-bzr/trunk/lisp/leim/quail/cyrillic hides /home/rms/emacs-bzr/trunk/lisp/language/cyrillic
/home/rms/emacs-bzr/trunk/lisp/leim/quail/indian hides /home/rms/emacs-bzr/trunk/lisp/language/indian
/home/rms/emacs-bzr/trunk/lisp/leim/quail/hebrew hides /home/rms/emacs-bzr/trunk/lisp/language/hebrew
/home/rms/emacs-bzr/trunk/lisp/leim/quail/greek hides /home/rms/emacs-bzr/trunk/lisp/language/greek
/home/rms/emacs-bzr/trunk/lisp/leim/quail/czech hides /home/rms/emacs-bzr/trunk/lisp/language/czech
/home/rms/emacs-bzr/trunk/lisp/leim/quail/slovak hides /home/rms/emacs-bzr/trunk/lisp/language/slovak
/home/rms/emacs-bzr/trunk/lisp/leim/quail/tibetan hides /home/rms/emacs-bzr/trunk/lisp/language/tibetan
/home/rms/emacs-bzr/trunk/lisp/emulation/crisp hides /home/rms/emacs-bzr/trunk/lisp/obsolete/crisp
/home/rms/emacs-bzr/trunk/lisp/emulation/tpu-extras hides /home/rms/emacs-bzr/trunk/lisp/obsolete/tpu-extras
/home/rms/emacs-bzr/trunk/lisp/emulation/tpu-edt hides /home/rms/emacs-bzr/trunk/lisp/obsolete/tpu-edt
/home/rms/emacs-bzr/trunk/lisp/emulation/tpu-mapper hides /home/rms/emacs-bzr/trunk/lisp/obsolete/tpu-mapper
/home/rms/emacs-bzr/trunk/lisp/iswitchb hides /home/rms/emacs-bzr/trunk/lisp/obsolete/iswitchb
/home/rms/emacs-bzr/trunk/lisp/emulation/vip hides /home/rms/emacs-bzr/trunk/lisp/obsolete/vip
/home/rms/emacs-bzr/trunk/lisp/emulation/vi hides /home/rms/emacs-bzr/trunk/lisp/obsolete/vi
/home/rms/emacs-bzr/trunk/lisp/emulation/ws-mode hides /home/rms/emacs-bzr/trunk/lisp/obsolete/ws-mode
/home/rms/emacs-bzr/trunk/lisp/emacs-lisp/gulp hides /home/rms/emacs-bzr/trunk/lisp/obsolete/gulp

Features:
(shadow emacsbug vc-arch vc-mtn vc-hg vc-git vc-sccs vc-svn vc-rcs
two-column cal-china lunar solar cal-dst cal-bahai cal-islam
cal-hebrew holidays hol-loaddefs battery calc calc-loaddefs calc-macs
compare-w tmm tabify imenu man vc-bzr find-func debug gnus-util
mailcap doc-view image-mode cl-loaddefs cl-lib tar-mode cal-move
cal-menu calendar cal-loaddefs novice ispell rmailkwd rect log-edit
pcvs-util add-log diff-mode easy-mmode vc vc-dispatcher parse-time
vc-cvs sgml-mode mule-util etags jka-compr dired-aux dabbrev quail
help-mode shell pcomplete grep compile comint ansi-color ring rmailout
misearch multi-isearch epa-mail mailalias epa derived epg epg-config
qp rmailsum rmailmm message sendmail format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader
mail-parse rfc2231 dired t-mouse package rmailedit rmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date paren
cus-start cus-load advice help-fns tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 8 375295 107675)
 (symbols 24 26751 0)
 (miscs 20 2896 4794)
 (strings 16 48615 15393)
 (string-bytes 1 1436460)
 (vectors 8 29108)
 (vector-slots 4 1480714 54740)
 (floats 8 639 253)
 (intervals 28 71956 4232)
 (buffers 512 173)
 (heap 1024 23318 1739))
[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> Date: Mon, 23 Jun 2014 11:26:46 -0400
> From: Richard Stallman <rms@gnu.org>
> 
> I get the impression that searching fontifies all the text
> it moves through.  Is that really necessary?  It is a big pain in the neck.

It should only fontify the displayed parts (and sometimes slightly
above and below), not everything.  I will take a look.

Can you compare what you see with some older version of Emacs, like
23.x?  I tried, and they all seem to be of approximately the same
speed (or lack thereof).

bug#17837: 24.4.50; Search very slow

[Stefan Monnier]

> Visit stallman.org/archives/2014-mar-jun.html and type `C-s
> interview'.  It takes a long time.  Repeat with C-s a few times; each
> time, it takes a long time.

It's not particularly slow for me.

> I get the impression that searching fontifies all the text
> it moves through.  Is that really necessary?  It is a big pain in the neck.

Search doesn't fontify, no.  Of course, to display position N, we need
to font-lock position N, and to font-lock position N, html-mode needs to
scan all positions between 1 and N to look for things like <!--, or
CDATA, or various other such escape codes, so the amount of work is
proportional to the distance.


        Stefan

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

Here's the profile, with today's trunk.  Looks like the function
called by syntax-ppss via funcall is the culprit.  The only funcall in
syntax-ppss calls syntax-begin-function, AFAICS.

  - command-execute                                                 672  94%
   - call-interactively                                             672  94%
    - funcall-interactively                                         672  94%
     - isearch-repeat-forward                                       663  93%
      - isearch-repeat                                              663  93%
       - isearch-update                                             655  92%
	- isearch-lazy-highlight-new-loop                           654  92%
	 - sit-for                                                  654  92%
	  - redisplay                                               654  92%
	   - redisplay_internal (C function)                        636  89%
	    - jit-lock-function                                     634  89%
	     - jit-lock-fontify-now                                 634  89%
	      - funcall                                             634  89%
	       - #<compiled 0x13152f7>                              634  89%
		- run-hook-with-args                                634  89%
		 - font-lock-fontify-region                         634  89%
		  - font-lock-default-fontify-region                634  89%
		   - font-lock-fontify-syntactically-region         631  89%
		    - syntax-propertize                             597  84%
		     - #<compiled 0x106c735>                        593  83%
		      - syntax-ppss                                 579  81%
		       - funcall                                    571  80%
			  #<compiled 0x106ced3>                     569  80%
		    - syntax-ppss                                    33   4%
		     - funcall                                       33   4%
			#<compiled 0x1448019>                        33   4%
		     font-lock-fontify-keywords-region                  2   0%
	    - find-image                                              2   0%
	       cond                                                   2   0%
       - isearch-search                                               8   1%
	- byte-code                                                   8   1%
	 - isearch-search-string                                      8   1%
	    search-forward-lax-whitespace                             8   1%
     - isearch-printing-char                                          7   0%
      - isearch-process-search-char                                   7   0%
       - isearch-process-search-string                                7   0%
	- isearch-search-and-update                                   7   0%
	 - isearch-update                                             7   0%
	  - isearch-lazy-highlight-new-loop                           7   0%
	   - sit-for                                                  7   0%
	    - redisplay                                               7   0%
	       redisplay_internal (C function)                        1   0%
     - execute-extended-command                                       1   0%
      - command-execute                                               1   0%
       - call-interactively                                           1   0%
	- funcall-interactively                                       1   0%
	   profiler-start                                             1   0%
     - minibuffer-complete                                            1   0%
      - completion-in-region                                          1   0%
       - completion--in-region                                        1   0%
	- #<compiled 0x145b655>                                       1   0%
	 - apply                                                      1   0%
	  - #<compiled 0x4bd08b>                                      1   0%
	   - completion--in-region-1                                  1   0%
	    - completion--do-completion                               1   0%
	     - completion-try-completion                              1   0%
	      - completion--nth-completion                            1   0%
	       - completion--some                                     1   0%
		- funcall                                             1   0%
		 - #<compiled 0x145b677>                              1   0%
		  - #<compiled 0x145b669>                             1   0%
		     completion-basic-try-completion                  1   0%
  - ...                                                              36   5%
     Automatic GC                                                    36   5%

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 23 Jun 2014 11:51:53 -0400
> Cc: 17837@debbugs.gnu.org
> 
> > Visit stallman.org/archives/2014-mar-jun.html and type `C-s
> > interview'.  It takes a long time.  Repeat with C-s a few times; each
> > time, it takes a long time.
> 
> It's not particularly slow for me.

Your machine is much faster.  Mine is fast too, but still the delay is
annoyingly evident.  As long as the next hit is on the same screenful,
it is fast, but when it is far away, it takes annoyingly long to get
there.  I even got a hourglass cursor one time.

bug#17837: 24.4.50; Search very slow

[Stefan Monnier]

>> It's not particularly slow for me.
> Your machine is much faster.

I doubt it.  I wasn't using my laptop, which is the only machine more
powerful than a netbook-style processor (I know it sounds odd, but my
desktops are less power than my laptops).
More specifically, I was using an AMD E-350 when I tried it.

Maybe I'm just used to things being slow.


        Stefan

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This one is even slower:

In some random buffer:

C-s honor  [to set the search default]
C-x b 2014-mar-jun.html RET
M-<
C-s C-s
[wait to find the first occurrence]
C-s [search for the second occurrence]

I counted around 45 seconds before it found the second occurrence.

In Emacs 23.2, the second occurrence takes only 7 seconds.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> Date: Mon, 23 Jun 2014 21:08:59 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, 17837@debbugs.gnu.org
> 
> C-s honor  [to set the search default]
> C-x b 2014-mar-jun.html RET
> M-<
> C-s C-s
> [wait to find the first occurrence]
> C-s [search for the second occurrence]
> 
> I counted around 45 seconds before it found the second occurrence.

For me, the first one is slower: about 5 to 6 sec.  The second
occurrence takes maybe 3.  Stefan, what's your timing?

> In Emacs 23.2, the second occurrence takes only 7 seconds.

Yes, I see some slowdown wrt 23.2, although not as drastic.  Are you
sure both binaries were compiled similarly, e.g. as far as compiler
optimization switches are concerned?

Anyway, you may wish to experiment with setting jit-lock-defer-time to
a non-nil value.  E.g., try setting it to 0.25 or 0.5 sec, and see if
that gives good results.

bug#17837: 24.4.50; Search very slow

[Stefan Monnier]

>> I counted around 45 seconds before it found the second occurrence.

Richard, was that in an "emacs -Q"?

> For me, the first one is slower: about 5 to 6 sec.  The second
> occurrence takes maybe 3.  Stefan, what's your timing?

Again trying it on my AMD E-350 machine, using the emacs-24 branch built
with -Og and enable-checking (on Debian testing), I get about half of
your times (about 2-3s for the first search and barely more than 1s for
the second).

Opening the file and doing M-> took 6s.
`emacs23' (Debian's build, i.e. probably with -O2 and without
enable-checking) took 4s for the M-> test.

On my fit-pc2 (Intel Atom, 1G RAM), the emacs-24 branch took 8s to do
the M->.
And on my Mele A2000 (i.e. Allwinner 1GHz A10 CPU with 512M of RAM), it
took 18s.

> Anyway, you may wish to experiment with setting jit-lock-defer-time to
> a non-nil value.  E.g., try setting it to 0.25 or 0.5 sec, and see if
> that gives good results.

I think we should first try and figure out why his second search takes
45s instead of a couple seconds (I expect his Longsoon might be slower
than my Atom, but not significantly slower than my little ARM machine).


        Stefan

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Yes, I see some slowdown wrt 23.2, although not as drastic.  Are you
    sure both binaries were compiled similarly, e.g. as far as compiler
    optimization switches are concerned?

Perhaps not.  The 23.2 was not built by me.  I picked it because it was
the oldest I have.

    Anyway, you may wish to experiment with setting jit-lock-defer-time to
    a non-nil value.  E.g., try setting it to 0.25 or 0.5 sec, and see if
    that gives good results.

I tried setting that to .1, and here's what happened.

I typed C-s C-s (which searched for "honor").  It found the first
occurrence and displayed it without fontifying that area.

Then I typed C-f and got no response.  I suspect it had already
started to highlight the other matches, and was fontifying the
regions where they occur.

The C-f was executed after 30 seconds or more.

The current code gives bad results with all settings of that variable.
The code needs to be fixed.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> I counted around 45 seconds before it found the second occurrence.

    Richard, was that in an "emacs -Q"?

No, but I got a fairly similar result just now with -Q.
It was 37 sec for the first "honor", then 27 sec for the second.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> Date: Tue, 24 Jun 2014 11:42:13 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: monnier@iro.umontreal.ca, 17837@debbugs.gnu.org
> 
>     Anyway, you may wish to experiment with setting jit-lock-defer-time to
>     a non-nil value.  E.g., try setting it to 0.25 or 0.5 sec, and see if
>     that gives good results.
> 
> I tried setting that to .1, and here's what happened.
> 
> I typed C-s C-s (which searched for "honor").  It found the first
> occurrence and displayed it without fontifying that area.
> 
> Then I typed C-f and got no response.  I suspect it had already
> started to highlight the other matches, and was fontifying the
> regions where they occur.
> 
> The C-f was executed after 30 seconds or more.

Does anything change if you set redisplay-dont-pause to nil?

Stefan, isn't jit-lock supposed to stop and relinquish control if
input is available?  I thought it did, but I cannot find any code to
that effect.  What am I missing?

bug#17837: 24.4.50; Search very slow

[Stefan Monnier]

> Stefan, isn't jit-lock supposed to stop and relinquish control if
> input is available?

No, it doesn't do any such thing (and in the non-deferred case it
probably shouldn't).  The closest I can think of is the stealth fontification
which checks input-pending-p, IIRC.

It would make sense to make the deferred case use while-no-input.


        Stefan

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Does anything change if you set redisplay-dont-pause to nil?

No, it does not change.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Does anything change if you set redisplay-dont-pause to nil?

No, it does not change.
I tried that with jit-lock-defer-time = nil and = .1.

However, there is no need to try more cases.
Once there is one case that reproducibly causes bad behavior,
using a debugger to figure out what happens in that case
gives the lowest expected time to understanding the problem.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> Date: Wed, 25 Jun 2014 07:28:53 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: 17837@debbugs.gnu.org
> 
> However, there is no need to try more cases.
> Once there is one case that reproducibly causes bad behavior,
> using a debugger to figure out what happens in that case
> gives the lowest expected time to understanding the problem.

There's no need to debug this, because the reason is painfully clear:
once JIT font-lock kicks in (as a side effect of displaying a new
screenful of data), it takes it sufficiently long time to fontify the
displayed text.  As long as it fontifies, Emacs doesn't return to the
main loop, and your input is not obeyed.

The things I suggested were meant to provide some workaround for you,
not to solve the root cause (which AFAIU cannot be solved until HTML
fontification is this heavy).

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This is a very painful problem when it happens, and I think it should
be fixed now.

The problem is not simple font-lock.  It is due to searching for
other matches for the search string.

That loop should pause for user input, as if it were a background
process.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Stefan Monnier]

> The problem is not simple font-lock.  It is due to searching for
> other matches for the search string.

What makes you think so?

Try to M-x profiler-start RET RET at the beginning and M-x profiler-report
RET at the end (and then C-u RET on the top entry).


        Stefan

bug#17837: 24.4.50; Search very slow

[Eli Zaretskii]

> Date: Wed, 25 Jun 2014 20:10:03 -0400
> From: Richard Stallman <rms@gnu.org>
> CC: 17837@debbugs.gnu.org
> 
> The problem is not simple font-lock.  It is due to searching for
> other matches for the search string.

If this were true, then setting isearch-lazy-highlight to nil ought to
make Isearch significantly faster for you.  I tried that and didn't
see any noticeable difference; do you?

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > The problem is not simple font-lock.  It is due to searching for
    > other matches for the search string.

    What makes you think so?

The profile output that was posted included the code that searches
for other matches.  At least, that's what ISTR.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    If this were true, then setting isearch-lazy-highlight to nil ought to
    make Isearch significantly faster for you.

That is true.

						I tried that and didn't
    see any noticeable difference; do you?

Well, I did see a big noticeable difference: after C-s C-s, Emacs got
stuck before even redisplaying point at the first occurrence of
"honor".

Since the bug did not go away, it wasn't due to highlighting the other
matches.  It must be that it simply happened within the highlighting
of the other matches, when that is enabled.

I tried M-x toggle-debug-on-quit and doing C-g while it was hung.
C-g only caused it to hang less, but did not get me a backtrace.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

bug#17837: 24.4.50; Search very slow

[Stefan Kangas]

Richard Stallman <rms@gnu.org> writes:

> Visit stallman.org/archives/2014-mar-jun.html and type `C-s
> interview'.  It takes a long time.  Repeat with C-s a few times; each
> time, it takes a long time.
>
> Disable Font Lock mode, and it becomes nice and fast.
>
> I get the impression that searching fontifies all the text
> it moves through.  Is that really necessary?  It is a big pain in the neck.

[This was reported in 2014.]

I've tried this:

0. emacs -Q
1. M-x eww RET stallman.org/archives/2014-mar-jun.html RET
2. C-s interview

And it's fast, pretty much instant, to type all that and go through the
matches.  Did Emacs get faster or is my machine just faster than what
you were using at the time of reporting this bug?  Or am I using the
wrong recipe to reproduce the issue?

bug#17837: 24.4.50; Search very slow

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I've tried this:
>
> 0. emacs -Q
> 1. M-x eww RET stallman.org/archives/2014-mar-jun.html RET
> 2. C-s interview
>
> And it's fast, pretty much instant, to type all that and go through the
> matches.  Did Emacs get faster or is my machine just faster than what
> you were using at the time of reporting this bug?  Or am I using the
> wrong recipe to reproduce the issue?

I think Richard meant that he downloaded the HTML and then opened the
HTML file in Emacs (since he mentions font-lock).

I'm not able to see anything slow going on when doing that, though --
searching for "interview" in that HTML buffer is instantaneous for me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#17837: 24.4.50; Search very slow

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think Richard meant that he downloaded the HTML and then opened the
> HTML file in Emacs (since he mentions font-lock).

Ah, okay.

> I'm not able to see anything slow going on when doing that, though --
> searching for "interview" in that HTML buffer is instantaneous for me.

Yup, same here.

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 0. emacs -Q
  > 1. M-x eww RET stallman.org/archives/2014-mar-jun.html RET
  > 2. C-s interview

Does eww render the page?  If so, that is a difference
from what I did.  I did not run a web browser.  I visited
that file.

You can get that with wget.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#17837: 24.4.50; Search very slow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think Richard meant that he downloaded the HTML and then opened the
  > HTML file in Emacs (since he mentions font-lock).

Yes.

  > I'm not able to see anything slow going on when doing that, though --
  > searching for "interview" in that HTML buffer is instantaneous for me.

It runs fast enough for me now, in master from May 10.
It looks like the bug is fixed.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#17837: 24.4.50; Search very slow

[Lars Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> It runs fast enough for me now, in master from May 10.
> It looks like the bug is fixed.

OK; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no