* bug#17837: 24.4.50; Search very slow
@ 2014-06-23 15:26 Richard Stallman
2014-06-23 15:47 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-23 15:26 UTC (permalink / raw)
To: 17837
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.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-23 15:26 bug#17837: 24.4.50; Search very slow Richard Stallman
@ 2014-06-23 15:47 ` Eli Zaretskii
2014-06-23 16:32 ` Eli Zaretskii
2014-06-23 15:51 ` Stefan Monnier
2021-09-19 22:14 ` Stefan Kangas
2 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-23 15:47 UTC (permalink / raw)
To: rms; +Cc: 17837
> 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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-23 15:47 ` Eli Zaretskii
@ 2014-06-23 16:32 ` Eli Zaretskii
0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-23 16:32 UTC (permalink / raw)
To: rms; +Cc: 17837
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%
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-23 15:26 bug#17837: 24.4.50; Search very slow Richard Stallman
2014-06-23 15:47 ` Eli Zaretskii
@ 2014-06-23 15:51 ` Stefan Monnier
2014-06-23 16:38 ` Eli Zaretskii
2021-09-19 22:14 ` Stefan Kangas
2 siblings, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2014-06-23 15:51 UTC (permalink / raw)
To: Richard Stallman; +Cc: 17837
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-23 15:51 ` Stefan Monnier
@ 2014-06-23 16:38 ` Eli Zaretskii
2014-06-23 21:15 ` Stefan Monnier
2014-06-24 1:08 ` Richard Stallman
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-23 16:38 UTC (permalink / raw)
To: Stefan Monnier; +Cc: rms, 17837
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-23 16:38 ` Eli Zaretskii
@ 2014-06-23 21:15 ` Stefan Monnier
2014-06-24 1:08 ` Richard Stallman
1 sibling, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2014-06-23 21:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, 17837
>> 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
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-23 16:38 ` Eli Zaretskii
2014-06-23 21:15 ` Stefan Monnier
@ 2014-06-24 1:08 ` Richard Stallman
2014-06-24 2:46 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2014-06-24 1:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-24 1:08 ` Richard Stallman
@ 2014-06-24 2:46 ` Eli Zaretskii
2014-06-24 15:06 ` Stefan Monnier
2014-06-24 15:42 ` Richard Stallman
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-24 2:46 UTC (permalink / raw)
To: rms; +Cc: 17837
> 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-24 2:46 ` Eli Zaretskii
@ 2014-06-24 15:06 ` Stefan Monnier
2014-06-24 15:43 ` Richard Stallman
2014-06-24 15:42 ` Richard Stallman
1 sibling, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2014-06-24 15:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, 17837
>> 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
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-24 15:06 ` Stefan Monnier
@ 2014-06-24 15:43 ` Richard Stallman
0 siblings, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-24 15:43 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-24 2:46 ` Eli Zaretskii
2014-06-24 15:06 ` Stefan Monnier
@ 2014-06-24 15:42 ` Richard Stallman
2014-06-24 15:59 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2014-06-24 15:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-24 15:42 ` Richard Stallman
@ 2014-06-24 15:59 ` Eli Zaretskii
2014-06-24 17:29 ` Stefan Monnier
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-24 15:59 UTC (permalink / raw)
To: rms; +Cc: 17837
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-24 15:59 ` Eli Zaretskii
@ 2014-06-24 17:29 ` Stefan Monnier
2014-06-25 11:28 ` Richard Stallman
2014-06-25 11:28 ` Richard Stallman
2 siblings, 0 replies; 27+ messages in thread
From: Stefan Monnier @ 2014-06-24 17:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, 17837
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-24 15:59 ` Eli Zaretskii
2014-06-24 17:29 ` Stefan Monnier
@ 2014-06-25 11:28 ` Richard Stallman
2014-06-25 11:28 ` Richard Stallman
2 siblings, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-25 11:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-24 15:59 ` Eli Zaretskii
2014-06-24 17:29 ` Stefan Monnier
2014-06-25 11:28 ` Richard Stallman
@ 2014-06-25 11:28 ` Richard Stallman
2014-06-25 13:28 ` Eli Zaretskii
2 siblings, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2014-06-25 11:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-25 11:28 ` Richard Stallman
@ 2014-06-25 13:28 ` Eli Zaretskii
2014-06-26 0:10 ` Richard Stallman
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-25 13:28 UTC (permalink / raw)
To: rms; +Cc: 17837
> 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).
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-25 13:28 ` Eli Zaretskii
@ 2014-06-26 0:10 ` Richard Stallman
2014-06-26 2:54 ` Stefan Monnier
2014-06-26 14:59 ` Eli Zaretskii
0 siblings, 2 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-26 0:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-26 0:10 ` Richard Stallman
@ 2014-06-26 2:54 ` Stefan Monnier
2014-06-26 18:39 ` Richard Stallman
2014-06-26 14:59 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2014-06-26 2:54 UTC (permalink / raw)
To: Richard Stallman; +Cc: 17837
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#17837: 24.4.50; Search very slow
2014-06-26 2:54 ` Stefan Monnier
@ 2014-06-26 18:39 ` Richard Stallman
0 siblings, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-26 18:39 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-26 0:10 ` Richard Stallman
2014-06-26 2:54 ` Stefan Monnier
@ 2014-06-26 14:59 ` Eli Zaretskii
2014-06-26 18:40 ` Richard Stallman
1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2014-06-26 14:59 UTC (permalink / raw)
To: rms; +Cc: 17837
> 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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-26 14:59 ` Eli Zaretskii
@ 2014-06-26 18:40 ` Richard Stallman
0 siblings, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2014-06-26 18:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 17837
[[[ 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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2014-06-23 15:26 bug#17837: 24.4.50; Search very slow Richard Stallman
2014-06-23 15:47 ` Eli Zaretskii
2014-06-23 15:51 ` Stefan Monnier
@ 2021-09-19 22:14 ` Stefan Kangas
2021-09-20 6:10 ` Lars Ingebrigtsen
2021-09-20 23:51 ` Richard Stallman
2 siblings, 2 replies; 27+ messages in thread
From: Stefan Kangas @ 2021-09-19 22:14 UTC (permalink / raw)
To: Richard Stallman; +Cc: 17837
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2021-09-19 22:14 ` Stefan Kangas
@ 2021-09-20 6:10 ` Lars Ingebrigtsen
2021-09-20 6:56 ` Stefan Kangas
2021-09-21 22:15 ` Richard Stallman
2021-09-20 23:51 ` Richard Stallman
1 sibling, 2 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-20 6:10 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Richard Stallman, 17837
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2021-09-20 6:10 ` Lars Ingebrigtsen
@ 2021-09-20 6:56 ` Stefan Kangas
2021-09-21 22:15 ` Richard Stallman
1 sibling, 0 replies; 27+ messages in thread
From: Stefan Kangas @ 2021-09-20 6:56 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Richard Stallman, 17837
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2021-09-20 6:10 ` Lars Ingebrigtsen
2021-09-20 6:56 ` Stefan Kangas
@ 2021-09-21 22:15 ` Richard Stallman
2021-09-21 22:16 ` Lars Ingebrigtsen
1 sibling, 1 reply; 27+ messages in thread
From: Richard Stallman @ 2021-09-21 22:15 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: stefan, 17837
[[[ 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)
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#17837: 24.4.50; Search very slow
2021-09-19 22:14 ` Stefan Kangas
2021-09-20 6:10 ` Lars Ingebrigtsen
@ 2021-09-20 23:51 ` Richard Stallman
1 sibling, 0 replies; 27+ messages in thread
From: Richard Stallman @ 2021-09-20 23:51 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 17837
[[[ 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)
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-09-21 22:16 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-23 15:26 bug#17837: 24.4.50; Search very slow Richard Stallman
2014-06-23 15:47 ` Eli Zaretskii
2014-06-23 16:32 ` Eli Zaretskii
2014-06-23 15:51 ` Stefan Monnier
2014-06-23 16:38 ` Eli Zaretskii
2014-06-23 21:15 ` Stefan Monnier
2014-06-24 1:08 ` Richard Stallman
2014-06-24 2:46 ` Eli Zaretskii
2014-06-24 15:06 ` Stefan Monnier
2014-06-24 15:43 ` Richard Stallman
2014-06-24 15:42 ` Richard Stallman
2014-06-24 15:59 ` Eli Zaretskii
2014-06-24 17:29 ` Stefan Monnier
2014-06-25 11:28 ` Richard Stallman
2014-06-25 11:28 ` Richard Stallman
2014-06-25 13:28 ` Eli Zaretskii
2014-06-26 0:10 ` Richard Stallman
2014-06-26 2:54 ` Stefan Monnier
2014-06-26 18:39 ` Richard Stallman
2014-06-26 14:59 ` Eli Zaretskii
2014-06-26 18:40 ` Richard Stallman
2021-09-19 22:14 ` Stefan Kangas
2021-09-20 6:10 ` Lars Ingebrigtsen
2021-09-20 6:56 ` Stefan Kangas
2021-09-21 22:15 ` Richard Stallman
2021-09-21 22:16 ` Lars Ingebrigtsen
2021-09-20 23:51 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).