GNU bug report logs - #4511
23.1; flyspell-mode slow editing near end of big html file

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (Emacs bug Tracking System)
To: Kevin Ryde <user42 <at> zip.com.au>
Subject: bug#4511 closed by Stefan Monnier <monnier <at> iro.umontreal.ca> (Re:
 bug#4511: 23.1; flyspell-mode slow editing near end of big html file)
Date: Wed, 23 Sep 2009 23:15:03 +0000

[Message part 1 (text/plain, inline)]

This is an automatic notification regarding your bug report
which was filed against the emacs package:

#4511: 23.1; flyspell-mode slow editing near end of big html file

It has been closed by Stefan Monnier <monnier <at> iro.umontreal.ca>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Stefan Monnier <monnier <at> iro.umontreal.ca> by
replying to this email.


-- 
4511: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4511
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Kevin Ryde <user42 <at> zip.com.au>
Subject: Re: bug#4511: 23.1; flyspell-mode slow editing near end of big html file
Date: Wed, 23 Sep 2009 19:06:04 -0400

>>> You need to pass it a `limit' argument.
>> I thought about that a bit.  The limit would be the immediately
>> preceding "<", ">", or "\n", since whichever of them is hit first
>> answers whether you're in a tag or not.

> (line-beginning-position) will do fine.

Installed,


        Stefan

[Message part 3 (message/rfc822, inline)]

From: Kevin Ryde <user42 <at> zip.com.au>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1; flyspell-mode slow editing near end of big html file
Date: Tue, 22 Sep 2009 08:24:38 +1000

[Message part 4 (text/plain, inline)]

When flyspell-mode is enabled in a big html file, and point is somewhere
near the end of the buffer, typing text or moving point with C-f and C-b
become sluggish, to the point of being nearly unusable.

(This is a regression from emacs 22, where flyspell-mode was fine on
such files.)

I expect "big file" is relative to cpu speed, but 300 kbytes is bad on
my slow pc (not an outrageously huge file).  To reproduce try this of
about 600 kbytes,

    (progn
      (switch-to-buffer "foo")
      (dotimes (i 50000) (insert (format "<p> abc def\n" i)))

      (html-mode)
      (flyspell-mode))

It takes a few seconds to create the buffer, but of course that's not
the bug.  The bad bit is if you move point around with C-f / C-b near
the end of the buffer, or type some plain text there outside of a <tag>,
where it's sluggish between keystrokes.  (Try upping the 50000 on a fast
cpu if necessary.)


I track the slowness to where `sgml-mode-flyspell-verify' does

    (looking-back "<[^>\n]*")

I take it this func is asking whether point is within a <tag> or not.
Does that regexp end up asking re-search-backward to consider every "<"
in the buffer or something, before deciding no match is possible?

I find it hugely faster to do an old fashioned skip-chars-backward as
below -- assuming I'm not mistaken that the "\n" in the existing
`looking-back' is supposed mean examining no more than the current line.

2009-09-21  Kevin Ryde  <user42 <at> zip.com.au>

	* textmodes/flyspell.el (sgml-mode-flyspell-verify): Use
	skip-chars-backward instead of looking-back, to avoid a very slow
	regexp match when far into a big buffer with a lots of "<" chars.

[flyspell.el.sgml-verify.diff (text/x-diff, inline)]

--- flyspell.el.~1.146.~	2009-09-18 08:23:13.000000000 +1000
+++ flyspell.el	2009-09-21 16:36:12.000000000 +1000
@@ -363,7 +363,9 @@
   "Function used for `flyspell-generic-check-word-predicate' in SGML mode."
   (not (save-excursion
 	 (or (looking-at "[^<\n]*>")
-	     (ispell-looking-back "<[^>\n]*")
+	     (save-excursion
+	       (skip-chars-backward "^<>\n")   ;; \n only look at current line
+	       (not (equal ?< (char-before)))) ;; "<" if in a tag
 	     (and (looking-at "[^&\n]*;")
 		  (ispell-looking-back "&[^;\n]*"))))))
 

[Message part 6 (text/plain, inline)]

In GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
 of 2009-08-03 on raven, modified by Debian
configured using `configure  '--build=i486-linux-gnu' '--host=i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.1/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.1/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'host_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default-enable-multibyte-characters: t

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.