* Setting bidi-paragraph-direction in comint modes @ 2012-02-14 6:35 Chong Yidong 2012-02-14 17:52 ` Stefan Monnier 2012-02-14 17:55 ` Eli Zaretskii 0 siblings, 2 replies; 10+ messages in thread From: Chong Yidong @ 2012-02-14 6:35 UTC (permalink / raw) To: emacs-devel Any objections to setting bidi-paragraph-direction to `left-to-right' in Comint and derived modes? The bidi code appears to lead to a performance regression. You can observe this with 1. emacs -Q 2. M-x shell RET 3. ls /usr/share/doc (Prints about 2000 lines on my computer) 4. Repeat step 3 many times. As the buffer gets to about 8000 lines, redisplay slows to a crawl. Setting bidi-paragraph-direction to `left-to-right' fixes this (mostly; it's still a touch slower than in Emacs 23). AFAICT, bidi paragraphs don't make sense in Comint-like modes anyway. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-14 6:35 Setting bidi-paragraph-direction in comint modes Chong Yidong @ 2012-02-14 17:52 ` Stefan Monnier 2012-02-14 17:55 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2012-02-14 17:52 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > Any objections to setting bidi-paragraph-direction to `left-to-right' in > Comint and derived modes? None from me, Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-14 6:35 Setting bidi-paragraph-direction in comint modes Chong Yidong 2012-02-14 17:52 ` Stefan Monnier @ 2012-02-14 17:55 ` Eli Zaretskii 2012-02-15 0:49 ` Chong Yidong 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2012-02-14 17:55 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@gnu.org> > Date: Tue, 14 Feb 2012 14:35:52 +0800 > > 1. emacs -Q > 2. M-x shell RET > 3. ls /usr/share/doc (Prints about 2000 lines on my computer) > 4. Repeat step 3 many times. > > As the buffer gets to about 8000 lines, redisplay slows to a crawl. I cannot reproduce this here. I tried the same in a directory with 2190 files, generated a 10K-line buffer with no empty lines, and I see no "crawl", only some minor slowdown. Maybe I didn't try the commands you did? Which Emacs commands caused such a slow redisplay on your machine? In any case, see this comment in bidi.c: /* On my 2005-vintage machine, searching back for paragraph start takes ~1 us per line. And bidi_paragraph_init is called 4 times when user types C-p. The number below limits each call to bidi_paragraph_init to about 10 ms. */ #define MAX_PARAGRAPH_SEARCH 7500 In my experience, 4 x 10 = 40 ms is not perceived as a terrible slowdown, and most machines people use today are faster than mine. This number was tuned to treat reasonably well hard cases such as the one described in bug #9470. > AFAICT, bidi paragraphs don't make sense in Comint-like modes > anyway. Unfortunately, it does: a console program that displays localized messages through gettext will need dynamic determination of the paragraph direction in bidirectional locales, to display the messages as users of those locales expect. In any case, I'd like first to reproduce the problem, and then look into its root cause. Somehow, I doubt that searching for the paragraph start is it, with the above limit in effect. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-14 17:55 ` Eli Zaretskii @ 2012-02-15 0:49 ` Chong Yidong 2012-02-15 4:01 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Chong Yidong @ 2012-02-15 0:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Chong Yidong <cyd@gnu.org> >> Date: Tue, 14 Feb 2012 14:35:52 +0800 >> >> 1. emacs -Q >> 2. M-x shell RET >> 3. ls /usr/share/doc (Prints about 2000 lines on my computer) >> 4. Repeat step 3 many times. >> >> As the buffer gets to about 8000 lines, redisplay slows to a crawl. > > I cannot reproduce this here. I tried the same in a directory with > 2190 files, generated a 10K-line buffer with no empty lines, and I see > no "crawl", only some minor slowdown. Maybe I didn't try the commands > you did? Which Emacs commands caused such a slow redisplay on your > machine? Like I said, it's simply `ls /usr/share/doc'. You say that there is "some minor slowdown": that's the same slowdown I'm referring to, I think. On my machine, the performance difference with and without bidi-paragraph-direction is extremely noticeable. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 0:49 ` Chong Yidong @ 2012-02-15 4:01 ` Eli Zaretskii 2012-02-15 6:24 ` Chong Yidong 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2012-02-15 4:01 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@gnu.org> > Cc: emacs-devel@gnu.org > Date: Wed, 15 Feb 2012 08:49:18 +0800 > > Like I said, it's simply `ls /usr/share/doc'. You mean, the insertion of the next chunk of text that arrives from `ls'? > You say that there is "some minor slowdown": that's the same slowdown > I'm referring to, I think. On my machine, the performance difference > with and without bidi-paragraph-direction is extremely noticeable. Can you quantify it? Like, how much time it takes to insert the first 2000 lines vs the last? I didn't look at the insertion itself, I tried the various cursor motion commands _after_ the output from `ls' was already in the buffer. Do you see the "crawl" there as well? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 4:01 ` Eli Zaretskii @ 2012-02-15 6:24 ` Chong Yidong 2012-02-15 17:01 ` Eli Zaretskii 2012-02-15 17:46 ` Johan Bockgård 0 siblings, 2 replies; 10+ messages in thread From: Chong Yidong @ 2012-02-15 6:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Chong Yidong <cyd@gnu.org> >> Cc: emacs-devel@gnu.org >> Date: Wed, 15 Feb 2012 08:49:18 +0800 >> >> Like I said, it's simply `ls /usr/share/doc'. > > You mean, the insertion of the next chunk of text that arrives from > `ls'? Yep. > I didn't look at the insertion itself, I tried the various cursor > motion commands _after_ the output from `ls' was already in the > buffer. Do you see the "crawl" there as well? Yep. After inserting about 7000 lines into the *shell* buffer, as described, press and hold down M-v (or PageUp) for several seconds. Redisplay freezes, not updating until about two seconds after the key is released. Then it updates the screen with the new cursor position. But if bidi-paragraph-direction is set to 'left-to-right, the display updates in real time as I press and hold M-v. > Can you quantify it? Like, how much time it takes to insert the first > 2000 lines vs the last? Not easily, but it is definitely not my imagination. You can't reproduce the problem at all? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 6:24 ` Chong Yidong @ 2012-02-15 17:01 ` Eli Zaretskii 2012-02-17 5:44 ` Chong Yidong 2012-02-15 17:46 ` Johan Bockgård 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2012-02-15 17:01 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > From: Chong Yidong <cyd@gnu.org> > Cc: emacs-devel@gnu.org > Date: Wed, 15 Feb 2012 14:24:11 +0800 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Chong Yidong <cyd@gnu.org> > >> Cc: emacs-devel@gnu.org > >> Date: Wed, 15 Feb 2012 08:49:18 +0800 > >> > >> Like I said, it's simply `ls /usr/share/doc'. > > > > You mean, the insertion of the next chunk of text that arrives from > > `ls'? > > Yep. I will time this and see how frequently are we looking for the paragraph beginning in this case. I never tried to time repeated insertions in small chunks, so I don't know what redisplay does in that case. > > I didn't look at the insertion itself, I tried the various cursor > > motion commands _after_ the output from `ls' was already in the > > buffer. Do you see the "crawl" there as well? > > Yep. After inserting about 7000 lines into the *shell* buffer, as > described, press and hold down M-v (or PageUp) for several seconds. > Redisplay freezes, not updating until about two seconds after the key is > released. Then it updates the screen with the new cursor position. I see nothing like that, the display never freezes. Strange. What kind of CPU do you have there? Is it a GUI session or a TTY session? Does Emacs run on the local machine or remote one? > > Can you quantify it? Like, how much time it takes to insert the first > > 2000 lines vs the last? > > Not easily, but it is definitely not my imagination. OK, I will do it myself. > You can't reproduce the problem at all? I see some slowdown, but I cannot in good faith characterize it as anything like "crawl", and M-v doesn't get stuck. This is on 7-year old single-core CPU at 3GHz, in an Emacs compiled without optimizations (-O0). On the same machine, an optimized build (-O2) runs significantly faster, so I see almost no slowdown at all. If you say "ls /usr/share/doc >> foo" 4 times and then visit the resulting file, do you see the same slow M-v in the buffer? Anyway, please make a bug report about this, and I will see what I can do about it. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 17:01 ` Eli Zaretskii @ 2012-02-17 5:44 ` Chong Yidong 0 siblings, 0 replies; 10+ messages in thread From: Chong Yidong @ 2012-02-17 5:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > Anyway, please make a bug report about this, and I will see what I can > do about it. See Bug#10835. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 6:24 ` Chong Yidong 2012-02-15 17:01 ` Eli Zaretskii @ 2012-02-15 17:46 ` Johan Bockgård 2012-02-15 18:33 ` Eli Zaretskii 1 sibling, 1 reply; 10+ messages in thread From: Johan Bockgård @ 2012-02-15 17:46 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@gnu.org> writes: > Not easily, but it is definitely not my imagination. You can't > reproduce the problem at all? FWIW, I see the effect of bidi-paragraph-direction on scrolling clearly after setting the keyboard repeat rate sufficiently high. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Setting bidi-paragraph-direction in comint modes 2012-02-15 17:46 ` Johan Bockgård @ 2012-02-15 18:33 ` Eli Zaretskii 0 siblings, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2012-02-15 18:33 UTC (permalink / raw) To: Johan Bockgård; +Cc: emacs-devel > From: Johan Bockgård <bojohan@gnu.org> > Date: Wed, 15 Feb 2012 18:46:48 +0100 > > Chong Yidong <cyd@gnu.org> writes: > > > Not easily, but it is definitely not my imagination. You can't > > reproduce the problem at all? > > FWIW, I see the effect of bidi-paragraph-direction on scrolling clearly > after setting the keyboard repeat rate sufficiently high. You can always outrun Emacs redisplay, even in Emacs 23, by setting the keyboard auto-repeat rate sufficiently high. That's not what this thread is about, clearly. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-02-17 5:44 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-14 6:35 Setting bidi-paragraph-direction in comint modes Chong Yidong 2012-02-14 17:52 ` Stefan Monnier 2012-02-14 17:55 ` Eli Zaretskii 2012-02-15 0:49 ` Chong Yidong 2012-02-15 4:01 ` Eli Zaretskii 2012-02-15 6:24 ` Chong Yidong 2012-02-15 17:01 ` Eli Zaretskii 2012-02-17 5:44 ` Chong Yidong 2012-02-15 17:46 ` Johan Bockgård 2012-02-15 18:33 ` Eli Zaretskii
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).