* bug#9470: 24.0.50; Possible bidi-related slowness
@ 2011-09-10 18:28 Lars Magne Ingebrigtsen
2011-09-10 18:45 ` Christoph Scholtes
2011-09-10 19:26 ` Eli Zaretskii
0 siblings, 2 replies; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 18:28 UTC (permalink / raw)
To: 9470
I just experienced a massively slow Gnus article buffer. The following
seems to reproduce the problem:
(progn
(pop-to-buffer "lala")
(dotimes (i 197000)
(insert "* 194624 FETCH (UID 194633 FLAGS (%Seen))\r\n* 194625 FETCH (UID 194634 FLAGS (%Seen))\r\n")))
If I hit `up' after that, Emacs takes about five seconds for each cursor
movement.
I haven't actually confirmed that this is bidi-related, though, but it's
a recentish regression.
In GNU Emacs 24.0.50.17 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
of 2011-09-10 on stories
Windowing system distributor `The X.Org Foundation', version 11.0.10707000
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_US
value of $XMODIFIERS: nil
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t
Major mode: Group
Minor modes in effect:
diff-auto-refine-mode: t
gnus-topic-mode: t
gnus-undo-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
Recent input:
s e n t SPC o u t , SPC t h i s SPC i s SPC s o m e
t h i n g SPC t h a t SPC n o SPC E m a c s SPC <M-backspace>
<M-backspace> f e w SPC E m a c s SPC u s e r s SPC
w i l l SPC b e SPC a b l e SPC t o SPC u s e , SPC
s i n c e SPC <M-backspace> <M-backspace> <M-backspace>
<M-backspace> u s i n g , SPC s i n c e SPC i f SPC
w e SPC c h a n g e SPC t h e SPC d e f a u l t SPC
t o SPC ` s e n d - m a i l = <backspace> - c l <backspace>
<backspace> u s i n g - t h e - c l e v e r - n e w
- l i n b u <backspace> <backspace> u x - a p i ' SPC
<backspace> , SPC t h e y ' l l SPC n e v e r SPC s
e e SPC i t . <up> <left> <left> <left> SPC i n SPC
E m a c s SPC 2 6 . 1 M-q C-c C-c D <return> q J S
g <up> <return> <return> <up> <return> P SPC <backspace>
<backspace> SPC SPC <backspace> <backspace> N C-x o
M-> <up> <up> <up> <up> <up> <up> i <next> M-> <up>
<up> <up> <up> <up> <down> M-= <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <up> C-SPC
<down> <down> M-w M-> M-= M-< M-= q M-x r e p o <tab>
r <tab> <return>
Recent messages:
Mark set
XZ uncompressing nnimap-buffer.txt.xz...done
XZ uncompressing nnimap-buffer.txt.xz...done
Mark set
Region has 194633 lines, 8019850 characters
Mark set [2 times]
Region has 15 lines, 497 characters
Mark set
Region has 194677 lines, 8021475 characters
Making completion list...
Load-path shadows:
/home/larsi/pgnus/lisp/compface hides ~/pgnus/contrib/compface
~/lisp/zenirc-2.112/src/zenirc-example hides /home/larsi/lisp/zenirc-example
~/pgnus/contrib/vcard hides /home/larsi/lisp/vcard
/home/larsi/src/clock.el/clock hides /home/larsi/lisp/clock
/home/larsi/src/cddb.el/expect hides /home/larsi/lisp/expect
/home/larsi/src/pvr.el/pvr hides /home/larsi/lisp/pvr
/home/larsi/pgnus/lisp/md4 hides /home/larsi/src/emacs/trunk/lisp/md4
/home/larsi/pgnus/lisp/color hides /home/larsi/src/emacs/trunk/lisp/color
/home/larsi/pgnus/lisp/format-spec hides /home/larsi/src/emacs/trunk/lisp/format-spec
/home/larsi/pgnus/lisp/password-cache hides /home/larsi/src/emacs/trunk/lisp/password-cache
/home/larsi/pgnus/lisp/hex-util hides /home/larsi/src/emacs/trunk/lisp/hex-util
/home/larsi/pgnus/lisp/dns-mode hides /home/larsi/src/emacs/trunk/lisp/textmodes/dns-mode
/home/larsi/pgnus/lisp/tls hides /home/larsi/src/emacs/trunk/lisp/net/tls
/home/larsi/pgnus/lisp/ntlm hides /home/larsi/src/emacs/trunk/lisp/net/ntlm
/home/larsi/pgnus/lisp/hmac-def hides /home/larsi/src/emacs/trunk/lisp/net/hmac-def
/home/larsi/pgnus/lisp/sasl-ntlm hides /home/larsi/src/emacs/trunk/lisp/net/sasl-ntlm
/home/larsi/pgnus/lisp/hmac-md5 hides /home/larsi/src/emacs/trunk/lisp/net/hmac-md5
/home/larsi/pgnus/lisp/dns hides /home/larsi/src/emacs/trunk/lisp/net/dns
/home/larsi/pgnus/lisp/imap hides /home/larsi/src/emacs/trunk/lisp/net/imap
/home/larsi/pgnus/lisp/dig hides /home/larsi/src/emacs/trunk/lisp/net/dig
/home/larsi/pgnus/lisp/sasl hides /home/larsi/src/emacs/trunk/lisp/net/sasl
/home/larsi/pgnus/lisp/sasl-cram hides /home/larsi/src/emacs/trunk/lisp/net/sasl-cram
/home/larsi/pgnus/lisp/netrc hides /home/larsi/src/emacs/trunk/lisp/net/netrc
/home/larsi/pgnus/lisp/sasl-digest hides /home/larsi/src/emacs/trunk/lisp/net/sasl-digest
/home/larsi/pgnus/lisp/hashcash hides /home/larsi/src/emacs/trunk/lisp/mail/hashcash
/home/larsi/pgnus/lisp/binhex hides /home/larsi/src/emacs/trunk/lisp/mail/binhex
/home/larsi/pgnus/lisp/uudecode hides /home/larsi/src/emacs/trunk/lisp/mail/uudecode
/home/larsi/pgnus/lisp/spam-report hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-report
/home/larsi/pgnus/lisp/gnus-sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sieve
/home/larsi/pgnus/lisp/rfc2045 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2045
/home/larsi/pgnus/lisp/gnus-salt hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-salt
/home/larsi/pgnus/lisp/gnus-gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-gravatar
/home/larsi/pgnus/lisp/utf7 hides /home/larsi/src/emacs/trunk/lisp/gnus/utf7
/home/larsi/pgnus/lisp/auth-source hides /home/larsi/src/emacs/trunk/lisp/gnus/auth-source
/home/larsi/pgnus/lisp/registry hides /home/larsi/src/emacs/trunk/lisp/gnus/registry
/home/larsi/pgnus/lisp/nndraft hides /home/larsi/src/emacs/trunk/lisp/gnus/nndraft
/home/larsi/pgnus/lisp/mm-partial hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-partial
/home/larsi/pgnus/lisp/plstore hides /home/larsi/src/emacs/trunk/lisp/gnus/plstore
/home/larsi/pgnus/lisp/gnus-cite hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cite
/home/larsi/pgnus/lisp/mm-url hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-url
/home/larsi/pgnus/lisp/nnmh hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmh
/home/larsi/pgnus/lisp/nnbabyl hides /home/larsi/src/emacs/trunk/lisp/gnus/nnbabyl
/home/larsi/pgnus/lisp/mm-extern hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-extern
/home/larsi/pgnus/lisp/mm-encode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-encode
/home/larsi/pgnus/lisp/gnus-sync hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sync
/home/larsi/pgnus/lisp/gnus-cus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cus
/home/larsi/pgnus/lisp/rfc2231 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2231
/home/larsi/pgnus/lisp/gnus-range hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-range
/home/larsi/pgnus/lisp/gnus-topic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-topic
/home/larsi/pgnus/lisp/gnus-diary hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-diary
/home/larsi/pgnus/lisp/flow-fill hides /home/larsi/src/emacs/trunk/lisp/gnus/flow-fill
/home/larsi/pgnus/lisp/gnus-eform hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-eform
/home/larsi/pgnus/lisp/gmm-utils hides /home/larsi/src/emacs/trunk/lisp/gnus/gmm-utils
/home/larsi/pgnus/lisp/gnus-vm hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-vm
/home/larsi/pgnus/lisp/gnus-demon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-demon
/home/larsi/pgnus/lisp/compface hides /home/larsi/src/emacs/trunk/lisp/gnus/compface
/home/larsi/pgnus/lisp/gnus-undo hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-undo
/home/larsi/pgnus/lisp/mail-parse hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-parse
/home/larsi/pgnus/lisp/gssapi hides /home/larsi/src/emacs/trunk/lisp/gnus/gssapi
/home/larsi/pgnus/lisp/score-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/score-mode
/home/larsi/pgnus/lisp/nnnil hides /home/larsi/src/emacs/trunk/lisp/gnus/nnnil
/home/larsi/pgnus/lisp/gnus-kill hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-kill
/home/larsi/pgnus/lisp/rfc2047 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2047
/home/larsi/pgnus/lisp/gnus-start hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-start
/home/larsi/pgnus/lisp/mml-smime hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-smime
/home/larsi/pgnus/lisp/nnmail hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmail
/home/larsi/pgnus/lisp/mml hides /home/larsi/src/emacs/trunk/lisp/gnus/mml
/home/larsi/pgnus/lisp/gnus-html hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-html
/home/larsi/pgnus/lisp/sieve-manage hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-manage
/home/larsi/pgnus/lisp/nnmaildir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmaildir
/home/larsi/pgnus/lisp/nnoo hides /home/larsi/src/emacs/trunk/lisp/gnus/nnoo
/home/larsi/pgnus/lisp/mm-decode hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-decode
/home/larsi/pgnus/lisp/rfc1843 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc1843
/home/larsi/pgnus/lisp/yenc hides /home/larsi/src/emacs/trunk/lisp/gnus/yenc
/home/larsi/pgnus/lisp/nnir hides /home/larsi/src/emacs/trunk/lisp/gnus/nnir
/home/larsi/pgnus/lisp/mml1991 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml1991
/home/larsi/pgnus/lisp/qp hides /home/larsi/src/emacs/trunk/lisp/gnus/qp
/home/larsi/pgnus/lisp/gnus-logic hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-logic
/home/larsi/pgnus/lisp/mm-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-uu
/home/larsi/pgnus/lisp/nnvirtual hides /home/larsi/src/emacs/trunk/lisp/gnus/nnvirtual
/home/larsi/pgnus/lisp/mail-prsvr hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-prsvr
/home/larsi/pgnus/lisp/mail-source hides /home/larsi/src/emacs/trunk/lisp/gnus/mail-source
/home/larsi/pgnus/lisp/gnus-group hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-group
/home/larsi/pgnus/lisp/mml-sec hides /home/larsi/src/emacs/trunk/lisp/gnus/mml-sec
/home/larsi/pgnus/lisp/mm-view hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-view
/home/larsi/pgnus/lisp/mm-bodies hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-bodies
/home/larsi/pgnus/lisp/gnus-registry hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-registry
/home/larsi/pgnus/lisp/nnml hides /home/larsi/src/emacs/trunk/lisp/gnus/nnml
/home/larsi/pgnus/lisp/sieve hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve
/home/larsi/pgnus/lisp/gnus-dup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dup
/home/larsi/pgnus/lisp/shr-color hides /home/larsi/src/emacs/trunk/lisp/gnus/shr-color
/home/larsi/pgnus/lisp/gnus-mh hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mh
/home/larsi/pgnus/lisp/gnus-async hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-async
/home/larsi/pgnus/lisp/nntp hides /home/larsi/src/emacs/trunk/lisp/gnus/nntp
/home/larsi/pgnus/lisp/pop3 hides /home/larsi/src/emacs/trunk/lisp/gnus/pop3
/home/larsi/pgnus/lisp/gnus-dired hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-dired
/home/larsi/pgnus/lisp/nnheader hides /home/larsi/src/emacs/trunk/lisp/gnus/nnheader
/home/larsi/pgnus/lisp/ecomplete hides /home/larsi/src/emacs/trunk/lisp/gnus/ecomplete
/home/larsi/pgnus/lisp/nnmairix hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmairix
/home/larsi/pgnus/lisp/gnus-srvr hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-srvr
/home/larsi/pgnus/lisp/canlock hides /home/larsi/src/emacs/trunk/lisp/gnus/canlock
/home/larsi/pgnus/lisp/starttls hides /home/larsi/src/emacs/trunk/lisp/gnus/starttls
/home/larsi/pgnus/lisp/html2text hides /home/larsi/src/emacs/trunk/lisp/gnus/html2text
/home/larsi/pgnus/lisp/gnus-bcklg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bcklg
/home/larsi/pgnus/lisp/gnus-score hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-score
/home/larsi/pgnus/lisp/nnfolder hides /home/larsi/src/emacs/trunk/lisp/gnus/nnfolder
/home/larsi/pgnus/lisp/nnagent hides /home/larsi/src/emacs/trunk/lisp/gnus/nnagent
/home/larsi/pgnus/lisp/nneething hides /home/larsi/src/emacs/trunk/lisp/gnus/nneething
/home/larsi/pgnus/lisp/shr hides /home/larsi/src/emacs/trunk/lisp/gnus/shr
/home/larsi/pgnus/lisp/gnus-msg hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-msg
/home/larsi/pgnus/lisp/rfc2104 hides /home/larsi/src/emacs/trunk/lisp/gnus/rfc2104
/home/larsi/pgnus/lisp/gnus-ems hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ems
/home/larsi/pgnus/lisp/gnus hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus
/home/larsi/pgnus/lisp/nnmbox hides /home/larsi/src/emacs/trunk/lisp/gnus/nnmbox
/home/larsi/pgnus/lisp/gnus-cache hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-cache
/home/larsi/pgnus/lisp/gnus-setup hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-setup
/home/larsi/pgnus/lisp/message hides /home/larsi/src/emacs/trunk/lisp/gnus/message
/home/larsi/pgnus/lisp/gnus-art hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-art
/home/larsi/pgnus/lisp/nnregistry hides /home/larsi/src/emacs/trunk/lisp/gnus/nnregistry
/home/larsi/pgnus/lisp/nnrss hides /home/larsi/src/emacs/trunk/lisp/gnus/nnrss
/home/larsi/pgnus/lisp/nnweb hides /home/larsi/src/emacs/trunk/lisp/gnus/nnweb
/home/larsi/pgnus/lisp/spam-stat hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-stat
/home/larsi/pgnus/lisp/mml2015 hides /home/larsi/src/emacs/trunk/lisp/gnus/mml2015
/home/larsi/pgnus/lisp/spam hides /home/larsi/src/emacs/trunk/lisp/gnus/spam
/home/larsi/pgnus/lisp/gravatar hides /home/larsi/src/emacs/trunk/lisp/gnus/gravatar
/home/larsi/pgnus/lisp/gnus-fun hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-fun
/home/larsi/pgnus/lisp/smiley hides /home/larsi/src/emacs/trunk/lisp/gnus/smiley
/home/larsi/pgnus/lisp/sieve-mode hides /home/larsi/src/emacs/trunk/lisp/gnus/sieve-mode
/home/larsi/pgnus/lisp/gnus-picon hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-picon
/home/larsi/pgnus/lisp/gnus-bookmark hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-bookmark
/home/larsi/pgnus/lisp/ietf-drums hides /home/larsi/src/emacs/trunk/lisp/gnus/ietf-drums
/home/larsi/pgnus/lisp/gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-agent
/home/larsi/pgnus/lisp/gnus-util hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-util
/home/larsi/pgnus/lisp/gnus-int hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-int
/home/larsi/pgnus/lisp/gnus-sum hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-sum
/home/larsi/pgnus/lisp/nndiary hides /home/larsi/src/emacs/trunk/lisp/gnus/nndiary
/home/larsi/pgnus/lisp/legacy-gnus-agent hides /home/larsi/src/emacs/trunk/lisp/gnus/legacy-gnus-agent
/home/larsi/pgnus/lisp/gnus-delay hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-delay
/home/larsi/pgnus/lisp/nngateway hides /home/larsi/src/emacs/trunk/lisp/gnus/nngateway
/home/larsi/pgnus/lisp/nnimap hides /home/larsi/src/emacs/trunk/lisp/gnus/nnimap
/home/larsi/pgnus/lisp/messcompat hides /home/larsi/src/emacs/trunk/lisp/gnus/messcompat
/home/larsi/pgnus/lisp/nndoc hides /home/larsi/src/emacs/trunk/lisp/gnus/nndoc
/home/larsi/pgnus/lisp/smime hides /home/larsi/src/emacs/trunk/lisp/gnus/smime
/home/larsi/pgnus/lisp/deuglify hides /home/larsi/src/emacs/trunk/lisp/gnus/deuglify
/home/larsi/pgnus/lisp/gnus-win hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-win
/home/larsi/pgnus/lisp/gnus-spec hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-spec
/home/larsi/pgnus/lisp/gnus-ml hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-ml
/home/larsi/pgnus/lisp/gnus-uu hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-uu
/home/larsi/pgnus/lisp/gnus-draft hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-draft
/home/larsi/pgnus/lisp/nndir hides /home/larsi/src/emacs/trunk/lisp/gnus/nndir
/home/larsi/pgnus/lisp/.dir-locals hides /home/larsi/src/emacs/trunk/lisp/gnus/.dir-locals
/home/larsi/pgnus/lisp/mailcap hides /home/larsi/src/emacs/trunk/lisp/gnus/mailcap
/home/larsi/pgnus/lisp/mm-util hides /home/larsi/src/emacs/trunk/lisp/gnus/mm-util
/home/larsi/pgnus/lisp/nnspool hides /home/larsi/src/emacs/trunk/lisp/gnus/nnspool
/home/larsi/pgnus/lisp/spam-wash hides /home/larsi/src/emacs/trunk/lisp/gnus/spam-wash
/home/larsi/pgnus/lisp/gnus-mlspl hides /home/larsi/src/emacs/trunk/lisp/gnus/gnus-mlspl
/home/larsi/pgnus/lisp/rtree hides /home/larsi/src/emacs/trunk/lisp/gnus/rtree
/home/larsi/pgnus/lisp/time-date hides /home/larsi/src/emacs/trunk/lisp/calendar/time-date
/home/larsi/pgnus/lisp/parse-time hides /home/larsi/src/emacs/trunk/lisp/calendar/parse-time
/home/larsi/pgnus/lisp/pgg-gpg hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg-gpg
/home/larsi/pgnus/lisp/pgg-pgp5 hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg-pgp5
/home/larsi/pgnus/lisp/pgg-def hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg-def
/home/larsi/pgnus/lisp/pgg-parse hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg-parse
/home/larsi/pgnus/lisp/pgg-pgp hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg-pgp
/home/larsi/pgnus/lisp/pgg hides /home/larsi/src/emacs/trunk/lisp/obsolete/pgg
Features:
(smerge-mode newcomment log-edit vc-sccs vc-svn vc-rcs vc-dir ewoc rect
kmacro whitespace log-view pcvs-util vc ediff-merg ediff-diff ediff-wind
ediff-help ediff-util ediff-mult ediff-init ediff vc-dispatcher etags
ring vc-bzr cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs url-handlers thingatpt flow-fill pp
diff-mode smiley ansi-color shr-color color timezone url-queue gnus-html
url-cache shr browse-url mailalias smtpmail sendmail gnus-bcklg
gnus-draft shadow sort emacsbug help-mode view gnus-cite ecomplete
multi-isearch mule-util gnus-async gnus-dup qp gnus-ml gmane spam-gmane
dns mm-url gnus-fun gnus-mdrtn gnus-topic nndoc nnmbox nndraft nnfolder
utf-7 nnimap parse-time utf7 gnutls rot13 disp-table netrc
network-stream starttls nnmh copyright vc-cvs nnagent nnml spam-report
spam spam-stat gnus-uu yenc gnus-agent gnus-srvr gnus-score score-mode
nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime
smime dig nntp gnus-cache nnir gnus-sum nnoo gnus-group gnus-undo nnmail
mail-source gnus-start gnus-spec gnus-int gnus-range message format-spec
rfc822 mml easymenu mml-sec mailabbrev gmm-utils mailheader gnus-win
gnus-load gnus gnus-ems nnheader mail-utils wid-edit uniquify advice
help-fns advice-preload debbugs-gnu easy-mmode derived tabulated-list
debbugs soap-client mm-decode mm-bodies mm-encode url-http tls url-auth
mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw url url-proxy
url-privacy url-expand url-methods url-history url-cookie url-util
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
macroexp assoc gnus-util password-cache url-vars mm-util mail-prsvr
mailcap warnings xml ido flyspell ispell dired regexp-opt add-log
mail-extr jka-compr cl time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image fringe
lisp-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 loaddefs button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dynamic-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 22+ messages in thread* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 18:28 bug#9470: 24.0.50; Possible bidi-related slowness Lars Magne Ingebrigtsen
@ 2011-09-10 18:45 ` Christoph Scholtes
2011-09-10 19:15 ` Eli Zaretskii
2011-09-10 19:26 ` Eli Zaretskii
1 sibling, 1 reply; 22+ messages in thread
From: Christoph Scholtes @ 2011-09-10 18:45 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470
On 9/10/2011 12:28 PM, Lars Magne Ingebrigtsen wrote:
> I just experienced a massively slow Gnus article buffer.
I noticed a slow scrolling behavior when editing a Python file also. I
am not sure if these issues are related.
Holding C-n shows the same skipping behavior I usually experience in big
c files. The cursor disappears and at some point it catches up. This
does however not happen when holding C-p to go upwards.
M-: (setq bidi-display-reordering nil)
solves the problem and C-n and C-p behave normally.
Disabling font-lock works also, so font-lock plus bidi-reordering is
probably too slow?
Eli, let me know if there is any way to help troubleshoot this.
Christoph
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 18:45 ` Christoph Scholtes
@ 2011-09-10 19:15 ` Eli Zaretskii
2011-09-10 20:28 ` Christoph Scholtes
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 19:15 UTC (permalink / raw)
To: Christoph Scholtes; +Cc: 9470, larsi
> Date: Sat, 10 Sep 2011 12:45:03 -0600
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: 9470@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>
> Eli, let me know if there is any way to help troubleshoot this.
I need a file where you see the slowdown, and customizations, if any,
needed to reproduce it starting with "emacs -Q".
TIA
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 19:15 ` Eli Zaretskii
@ 2011-09-10 20:28 ` Christoph Scholtes
0 siblings, 0 replies; 22+ messages in thread
From: Christoph Scholtes @ 2011-09-10 20:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470
On 9/10/2011 1:15 PM, Eli Zaretskii wrote:
> I need a file where you see the slowdown, and customizations, if any,
> needed to reproduce it starting with "emacs -Q".
Sorry, I don't think this is bidi-related. At least not directly. I use
an alternative python-mode which turns out, is less efficient when it
comes to font-lock than the stock emacs mode. The more modes,
anti-aliased fonts etc. are enabled, the more the described behavior
shows. Enabling/disabling bidi-reordering probably just took some load
off of the system. Using the default font instead of Consolas 9 made the
problem go away also.
Sorry for the noise.
Christoph
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 18:28 bug#9470: 24.0.50; Possible bidi-related slowness Lars Magne Ingebrigtsen
2011-09-10 18:45 ` Christoph Scholtes
@ 2011-09-10 19:26 ` Eli Zaretskii
2011-09-10 19:25 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 19:26 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470-done
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Sat, 10 Sep 2011 20:28:49 +0200
>
> I just experienced a massively slow Gnus article buffer. The
> following
> seems to reproduce the problem:
>
> (progn
> (pop-to-buffer "lala")
> (dotimes (i 197000)
> (insert "* 194624 FETCH (UID 194633 FLAGS (%Seen))\r\n* 194625
> FETCH (UID 194634 FLAGS (%Seen))\r\n")))
>
> If I hit `up' after that, Emacs takes about five seconds for each
> cursor
> movement.
Set bidi-paragraph-direction to `left-to-right', and the problem is
gone.
Such buffers should _always_ have bidi-paragraph-direction set like
that.
I'm closing this bug.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 19:26 ` Eli Zaretskii
@ 2011-09-10 19:25 ` Lars Magne Ingebrigtsen
2011-09-10 19:41 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 19:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470
Eli Zaretskii <eliz@gnu.org> writes:
> Set bidi-paragraph-direction to `left-to-right', and the problem is
> gone.
>
> Such buffers should _always_ have bidi-paragraph-direction set like
> that.
Uhm. This is the Gnus article buffer. You don't think the Gnus article
buffer should be able to display R2L text? Okidoke.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 19:25 ` Lars Magne Ingebrigtsen
@ 2011-09-10 19:41 ` Eli Zaretskii
2011-09-10 19:41 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 19:41 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 9470@debbugs.gnu.org
> Date: Sat, 10 Sep 2011 21:25:21 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Set bidi-paragraph-direction to `left-to-right', and the problem
> > is
> > gone.
> >
> > Such buffers should _always_ have bidi-paragraph-direction set
> > like
> > that.
>
> Uhm. This is the Gnus article buffer. You don't think the Gnus
> article
> buffer should be able to display R2L text? Okidoke.
Surely, I cannot possibly want that, can I? That setting just tells
Emacs to display text starting at the left margin of the window. It
doesn't stop reordering R2L text for display (see the node
"Bidirectional Display" in the ELisp manual).
Anyway, what do you mean by "article buffer"? (I don't use Gnus.)
What does it display? If it displays text of a single article, then
how come you gave me text is an infinite sequence of identical lines?
Can you show me a _real_ article that triggers slow display?
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 19:41 ` Eli Zaretskii
@ 2011-09-10 19:41 ` Lars Magne Ingebrigtsen
2011-09-10 20:10 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 19:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470
Eli Zaretskii <eliz@gnu.org> writes:
> Surely, I cannot possibly want that, can I?
No, it sounded odd. :-)
> That setting just tells Emacs to display text starting at the left
> margin of the window. It doesn't stop reordering R2L text for display
> (see the node "Bidirectional Display" in the ELisp manual).
Hm. Then why isn't that the default, then?
> Anyway, what do you mean by "article buffer"? (I don't use Gnus.)
> What does it display? If it displays text of a single article, then
> how come you gave me text is an infinite sequence of identical lines?
It displays the text of a single article.
This particular article was mainly composed of 197K lines looking like
that. There was a paragraph at the beginning.
(It was an IMAP bug report.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 19:41 ` Lars Magne Ingebrigtsen
@ 2011-09-10 20:10 ` Eli Zaretskii
2011-09-10 20:11 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 20:10 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 9470@debbugs.gnu.org
> Date: Sat, 10 Sep 2011 21:41:44 +0200
>
> > That setting just tells Emacs to display text starting at the left
> > margin of the window. It doesn't stop reordering R2L text for
> > display
> > (see the node "Bidirectional Display" in the ELisp manual).
>
> Hm. Then why isn't that the default, then?
Because, if the paragraph consists of mostly R2L text, displaying it
from the left margin would not be TRT, it looks ugly.
Left-to-right paragraphs _are_ the default in modes where we know in
advance that we will be displaying predominantly L2R text, such as in
any mode that inherits from prog-mode. But in modes that display
human-written text paragraph direction is determined dynamically as
part of redisplay, and that can be very expensive when you are near
the end of a large buffer that is a single paragraph.
> > Anyway, what do you mean by "article buffer"? (I don't use Gnus.)
> > What does it display? If it displays text of a single article,
> > then
> > how come you gave me text is an infinite sequence of identical
> > lines?
>
> It displays the text of a single article.
>
> This particular article was mainly composed of 197K lines looking
> like
> that. There was a paragraph at the beginning.
>
> (It was an IMAP bug report.)
Then I don't see how can I fix this specific case. The bidi display
must know the paragraph direction in order to DTRT. Ideas are
welcome. Doing something simple, like force left-to-right paragraph
direction if paragraph start isn't found in N lines, doesn't sound
right, as this will cause different display depending on how far we
are from the text beginning. Hmmm...
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:10 ` Eli Zaretskii
@ 2011-09-10 20:11 ` Lars Magne Ingebrigtsen
2011-09-10 20:34 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 20:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470
Eli Zaretskii <eliz@gnu.org> writes:
> Then I don't see how can I fix this specific case. The bidi display
> must know the paragraph direction in order to DTRT. Ideas are
> welcome. Doing something simple, like force left-to-right paragraph
> direction if paragraph start isn't found in N lines, doesn't sound
> right, as this will cause different display depending on how far we
> are from the text beginning. Hmmm...
If the algorithm has looked at N lines (where N is a reasonably big
number, like 10K), and found nothing exciting, then it would be
reasonable to bail out, won't it? "Paragraphs" like the one presented,
with 200K lines, are a pretty terminal case, and no "real" text ever
looks like that. I think.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:11 ` Lars Magne Ingebrigtsen
@ 2011-09-10 20:34 ` Eli Zaretskii
2011-09-10 20:42 ` Lars Magne Ingebrigtsen
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 20:34 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 9470@debbugs.gnu.org
> Date: Sat, 10 Sep 2011 22:11:08 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Then I don't see how can I fix this specific case. The bidi display
> > must know the paragraph direction in order to DTRT. Ideas are
> > welcome. Doing something simple, like force left-to-right paragraph
> > direction if paragraph start isn't found in N lines, doesn't sound
> > right, as this will cause different display depending on how far we
> > are from the text beginning. Hmmm...
>
> If the algorithm has looked at N lines (where N is a reasonably big
> number, like 10K), and found nothing exciting, then it would be
> reasonable to bail out, won't it?
The question is, what is "exciting", and what should we do when we
"bail out"?
If by "exciting" you mean the paragraph beginning, then the question
of the paragraph direction is still there.
> "Paragraphs" like the one presented, with 200K lines, are a pretty
> terminal case, and no "real" text ever looks like that. I think.
Right, but I can easily concoct an example of equally un-exciting
long paragraph that is full of R2L text, and should be displayed
starting at the right margin of the window.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:34 ` Eli Zaretskii
@ 2011-09-10 20:42 ` Lars Magne Ingebrigtsen
2011-09-10 20:53 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Lars Magne Ingebrigtsen @ 2011-09-10 20:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470
Eli Zaretskii <eliz@gnu.org> writes:
> The question is, what is "exciting", and what should we do when we
> "bail out"?
I defer to you what would be exciting. :-) I would have thought the
presence of no strongly R2L characters would be a measure of
non-excitingness...
>> "Paragraphs" like the one presented, with 200K lines, are a pretty
>> terminal case, and no "real" text ever looks like that. I think.
>
> Right, but I can easily concoct an example of equally un-exciting
> long paragraph that is full of R2L text, and should be displayed
> starting at the right margin of the window.
A R2L paragraph that doesn't have any R2L characters in the first 200K
lines checked? I'm sceptical about how many of those you find in real
life. :-)
Being emailed huge logs of various kinds is not uncommon, though.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog http://lars.ingebrigtsen.no/
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:42 ` Lars Magne Ingebrigtsen
@ 2011-09-10 20:53 ` Eli Zaretskii
2011-09-11 3:06 ` Stefan Monnier
2011-09-17 15:22 ` Eli Zaretskii
0 siblings, 2 replies; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-10 20:53 UTC (permalink / raw)
To: Lars Magne Ingebrigtsen; +Cc: 9470
> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: 9470@debbugs.gnu.org
> Date: Sat, 10 Sep 2011 22:42:31 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The question is, what is "exciting", and what should we do when we
> > "bail out"?
>
> I defer to you what would be exciting. :-) I would have thought the
> presence of no strongly R2L characters would be a measure of
> non-excitingness...
The long search is for the paragraph beginning. Looking for R2L
characters during that search will slow it even more.
Anyway, I reopened the bug and will try to think of something.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:53 ` Eli Zaretskii
@ 2011-09-11 3:06 ` Stefan Monnier
2011-09-11 4:59 ` Eli Zaretskii
2011-09-17 15:22 ` Eli Zaretskii
1 sibling, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-11 3:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470, Lars Magne Ingebrigtsen
>> > The question is, what is "exciting", and what should we do when we
>> > "bail out"?
>> I defer to you what would be exciting. :-) I would have thought the
>> presence of no strongly R2L characters would be a measure of
>> non-excitingness...
> The long search is for the paragraph beginning. Looking for R2L
> characters during that search will slow it even more.
> Anyway, I reopened the bug and will try to think of something.
I think Lars's point is a good one: maybe the paragraph direction can be
based on the predominance of L2R or R2L chars in the previous N chars,
in case the paragraph beginning is further than that (N should be large
enough to include all chars displayed).
Otherwise, I think the only way to make it faster is by caching the
result of the computation (I suspect you already do some caching, but
maybe we just need to be more aggressive).
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-11 3:06 ` Stefan Monnier
@ 2011-09-11 4:59 ` Eli Zaretskii
2011-09-11 5:18 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-11 4:59 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9470, larsi
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Lars Magne Ingebrigtsen <larsi@gnus.org>, 9470@debbugs.gnu.org
> Date: Sat, 10 Sep 2011 23:06:06 -0400
>
> > The long search is for the paragraph beginning. Looking for R2L
> > characters during that search will slow it even more.
> > Anyway, I reopened the bug and will try to think of something.
>
> I think Lars's point is a good one: maybe the paragraph direction can be
> based on the predominance of L2R or R2L chars in the previous N chars,
> in case the paragraph beginning is further than that (N should be large
> enough to include all chars displayed).
It might be a good idea in general, but I don't see how it would help
in this case, as I pointed out above.
Let me explain a bit more.
The current code works by searching backwards for a line that begins
with certain regexp. Unless someone can show a _really_ fast way of
counting types of characters we move across while searching for that
regexp, such counting will just make redisplay slower yet.
What bothers me even more is that such heuristics will give chaotic
results: adding a single character in some strategic place, or moving
up or down by a single line, can change the paragraph direction, with
dramatic effect on display. It will also effectively disable the
try_cursor_movement optimization (because the glyph matrix will be
entirely different), which is a big loss for users that just move
cursor.
So I generally favor a less smart algorithm, but one that gives
predictably constant results in a given buffer, and does not force us
to disable redisplay optimizations, even if it will sometimes produce
incorrect results. I have a simple idea for such an algorithm, but I
need to test it first.
> Otherwise, I think the only way to make it faster is by caching the
> result of the computation (I suspect you already do some caching, but
> maybe we just need to be more aggressive).
The caching is done in the iterator structure for the paragraph
through which the display engine iterates while preparing it for
display. The problem is that every redisplay cycle following a
command must begin by computing the paragraph direction of the first
paragraph whose text is about to be displayed. (Any following
paragraphs have their direction computed on the fly when we iterate
through their beginning.) And that first paragraph is what takes time
in these pathological buffers, especially when user types commands
that don't require complete redisplay of a window, and thus are
expected to be fast.
I don't see any easy way of gaining from more aggressive caching of
this info, because the cache would need to be updated on every edit
and on any redisplay, which would just move the slowdown from one
group of commands to another. Clever ideas are welcome.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-11 4:59 ` Eli Zaretskii
@ 2011-09-11 5:18 ` Stefan Monnier
2011-09-11 6:25 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-11 5:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470, larsi
> I don't see any easy way of gaining from more aggressive caching of
> this info, because the cache would need to be updated on every edit
> and on any redisplay, which would just move the slowdown from one
> group of commands to another. Clever ideas are welcome.
I'd guess that a cache that stores (START . END) could help, where
"START is a position that starts a paragraph and that paragraph ends no
sooner than END".
This way when working within a very long paragraph, you only need to
look for a paragraph boundary between END and point and if there isn't
any, you can go straight to START without searching for it.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-11 5:18 ` Stefan Monnier
@ 2011-09-11 6:25 ` Eli Zaretskii
2011-09-12 2:49 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-11 6:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9470, larsi
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org, 9470@debbugs.gnu.org
> Date: Sun, 11 Sep 2011 01:18:17 -0400
>
> I'd guess that a cache that stores (START . END) could help, where
> "START is a position that starts a paragraph and that paragraph ends no
> sooner than END".
>
> This way when working within a very long paragraph, you only need to
> look for a paragraph boundary between END and point and if there isn't
> any, you can go straight to START without searching for it.
I'm not sure I'm following. Are you assuming that redisplay is
entered immediately after each deletion or insertion, and therefore
these edits are always at point? Because that assumption is false,
AFAIK: Emacs could perform any number of edits before reentering
redisplay, so changes could be at places that are not at point and not
even in the visible portion of the buffer. Any of these edits could
insert or delete a paragraph boundary, and thus potentially change the
paragraph direction.
If you don't assume changes at point, then I don't see how point is
relevant to this issue. Am I missing something?
There are other complications with your proposal, e.g. the need to
look for and keep track of paragraph end, which I currently don't care
about, and the need to recompute the values of START and END when
point moves far way. But the above is the major one.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-11 6:25 ` Eli Zaretskii
@ 2011-09-12 2:49 ` Stefan Monnier
2011-09-12 7:21 ` Eli Zaretskii
0 siblings, 1 reply; 22+ messages in thread
From: Stefan Monnier @ 2011-09-12 2:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470, larsi
>> I'd guess that a cache that stores (START . END) could help, where
>> "START is a position that starts a paragraph and that paragraph ends no
>> sooner than END".
>> This way when working within a very long paragraph, you only need to
>> look for a paragraph boundary between END and point and if there isn't
>> any, you can go straight to START without searching for it.
> I'm not sure I'm following. Are you assuming that redisplay is
> entered immediately after each deletion or insertion, and therefore
> these edits are always at point?
No. I do assume we have some way to flush the cache (or parts thereof)
that become invalid, tho.
> Any of these edits could insert or delete a paragraph boundary, and
> thus potentially change the paragraph direction.
Sure. But if there aren't any edits, the cache is still valid. And if
there are edits before START of after END, then the cache can still be
valid (tho it may need START to be a marker, of course).
> If you don't assume changes at point, then I don't see how point is
> relevant to this issue. Am I missing something?
By "point" I just meant "the position we're interested in",
i.e. probably the first position of the text we're rendering.
> There are other complications with your proposal, e.g. the need to
> look for and keep track of paragraph end, which I currently don't care
> about, and the need to recompute the values of START and END when
> point moves far way. But the above is the major one.
I'm sure there are complications and that it won't remove
all slowdowns. But it should help the case in point (movement in
a very long paragraph) by only suffering the slow "find paragraph
beginning" once rather than for every command.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-12 2:49 ` Stefan Monnier
@ 2011-09-12 7:21 ` Eli Zaretskii
2011-09-13 2:21 ` Stefan Monnier
0 siblings, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-12 7:21 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9470, larsi
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: larsi@gnus.org, 9470@debbugs.gnu.org
> Date: Sun, 11 Sep 2011 22:49:23 -0400
>
> I do assume we have some way to flush the cache (or parts thereof)
> that become invalid, tho.
If we add the necessary code to prepare_to_modify_buffer, yes. That
code will need to either update the START and END positions or
invalidate the cache, depending on what modification is about to
happen. But not if the change is to add or remove text properties.
We will also need to invalidate the cache whenever the iterator
position winds up outside the (START..END) region, and update it as we
cross paragraph boundaries during iteration. And that's just result
of 5 minutes of thinking and zero testing.
> > Any of these edits could insert or delete a paragraph boundary, and
> > thus potentially change the paragraph direction.
>
> Sure. But if there aren't any edits, the cache is still valid.
If there are no edits _and_ point didn't move before START or far
after END.
> I'm sure there are complications and that it won't remove
> all slowdowns. But it should help the case in point (movement in
> a very long paragraph) by only suffering the slow "find paragraph
> beginning" once rather than for every command.
Having the first command take 5 seconds is still going to annoy. We
must get it below 0.5 sec to make it acceptable. And commands that
will invalidate the cache and cause slow display and unresponsive
Emacs are still a plenty. So this cannot be the whole solution. And
the logic described above is not trivial.
So for Emacs 24.1, I would go with a simpler solution which will solve
all the use cases, probably 90+ percent of them correctly: if a
paragraph boundary is not found after searching for a while, go to
point-min. I will try to code it soon and see if this works well
enough.
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-12 7:21 ` Eli Zaretskii
@ 2011-09-13 2:21 ` Stefan Monnier
0 siblings, 0 replies; 22+ messages in thread
From: Stefan Monnier @ 2011-09-13 2:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9470, larsi
>> I do assume we have some way to flush the cache (or parts thereof)
>> that become invalid, tho.
> If we add the necessary code to prepare_to_modify_buffer, yes. That
> code will need to either update the START and END positions or
> invalidate the cache, depending on what modification is about to
> happen. But not if the change is to add or remove text properties.
We don't have to pay attention to text properties, but I guess you're
right that the cache can surprive changes to text-properties.
> We will also need to invalidate the cache whenever the iterator
> position winds up outside the (START..END) region, and update it as we
> cross paragraph boundaries during iteration.
I don't see why, in general (you'd just flush the cache when a request
comes in for a different paragraph, i.e. to make room for another piece
of data), but in either case I don't think it would make much of
a difference, since the main use case if for a very long paragraph which
presumably covers the whole window.
>> > Any of these edits could insert or delete a paragraph boundary, and
>> > thus potentially change the paragraph direction.
>> Sure. But if there aren't any edits, the cache is still valid.
> If there are no edits _and_ point didn't move before START or far
> after END.
Right: movement within a paragraph. If there are edits nearby, you can
still re-scan from the edits, so it's still fast.
> Having the first command take 5 seconds is still going to annoy. We
Yes. Improvement to the worst case is better.
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9470: 24.0.50; Possible bidi-related slowness
2011-09-10 20:53 ` Eli Zaretskii
2011-09-11 3:06 ` Stefan Monnier
@ 2011-09-17 15:22 ` Eli Zaretskii
2011-09-18 7:33 ` Lars Magne Ingebrigtsen
1 sibling, 1 reply; 22+ messages in thread
From: Eli Zaretskii @ 2011-09-17 15:22 UTC (permalink / raw)
To: larsi; +Cc: 9470-done
> Date: Sat, 10 Sep 2011 23:53:30 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9470@debbugs.gnu.org
>
> > From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> > Cc: 9470@debbugs.gnu.org
> > Date: Sat, 10 Sep 2011 22:42:31 +0200
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > The question is, what is "exciting", and what should we do when we
> > > "bail out"?
> >
> > I defer to you what would be exciting. :-) I would have thought the
> > presence of no strongly R2L characters would be a measure of
> > non-excitingness...
>
> The long search is for the paragraph beginning. Looking for R2L
> characters during that search will slow it even more.
>
> Anyway, I reopened the bug and will try to think of something.
I committed a fix (revno 105807) that should keep the search for
paragraph beginning at bay. Using your example, redisplay is now as
fast (or as slow ;-) as elsewhere.
I'm closing this bug. Feel free to reopen if there are any
left-overs, or file a new bug if I caused regressions elsewhere.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-09-18 7:33 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-10 18:28 bug#9470: 24.0.50; Possible bidi-related slowness Lars Magne Ingebrigtsen
2011-09-10 18:45 ` Christoph Scholtes
2011-09-10 19:15 ` Eli Zaretskii
2011-09-10 20:28 ` Christoph Scholtes
2011-09-10 19:26 ` Eli Zaretskii
2011-09-10 19:25 ` Lars Magne Ingebrigtsen
2011-09-10 19:41 ` Eli Zaretskii
2011-09-10 19:41 ` Lars Magne Ingebrigtsen
2011-09-10 20:10 ` Eli Zaretskii
2011-09-10 20:11 ` Lars Magne Ingebrigtsen
2011-09-10 20:34 ` Eli Zaretskii
2011-09-10 20:42 ` Lars Magne Ingebrigtsen
2011-09-10 20:53 ` Eli Zaretskii
2011-09-11 3:06 ` Stefan Monnier
2011-09-11 4:59 ` Eli Zaretskii
2011-09-11 5:18 ` Stefan Monnier
2011-09-11 6:25 ` Eli Zaretskii
2011-09-12 2:49 ` Stefan Monnier
2011-09-12 7:21 ` Eli Zaretskii
2011-09-13 2:21 ` Stefan Monnier
2011-09-17 15:22 ` Eli Zaretskii
2011-09-18 7:33 ` Lars Magne Ingebrigtsen
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).