GNU bug report logs -
#17404
Scrolling is painfully slow
Previous Next
Reported by: rms <at> gnu.org
Date: Mon, 5 May 2014 07:00:03 UTC
Severity: normal
Tags: moreinfo
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17404 in the body.
You can then email your comments to 17404 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Mon, 05 May 2014 07:00:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 05 May 2014 07:00:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[[[ 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. ]]]
[19295] 2014-05-01 17:15:29.522 INFO: Updated to revision 117039 of branch bzr+ssh://rms <at> bzr.savannah.gnu.org/emacs/trunk
If you visit the file below in Rmail and type C-s GNU Emacs,
then C-n takes around 15 seconds.
SPC after that takes around 5 seconds.
[foo2.mail (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
--
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Mon, 05 May 2014 08:44:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 17404 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 05 May 2014 02:59:28 -0400
> From: Richard Stallman <rms <at> gnu.org>
>
> [19295] 2014-05-01 17:15:29.522 INFO: Updated to revision 117039 of branch bzr+ssh://rms <at> bzr.savannah.gnu.org/emacs/trunk
>
> If you visit the file below in Rmail and type C-s GNU Emacs,
> then C-n takes around 15 seconds.
It takes less than 0.5 sec here. My machine is faster than yours, but
I doubt that it's 30 times faster.
That file has 2 very long lines, one 42K characters long, the other
80K characters long, and Emacs display engine is known to be very slow
with such long lines.
If you have older Emacs 24.x installations somewhere, can you try the
same with those? I don't think something's changed significantly in
this area since Emacs 24.1, where bidirectional display slowed such
long lines some more.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Tue, 06 May 2014 11:43:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 17404 <at> debbugs.gnu.org (full text, mbox):
[[[ 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 you have older Emacs 24.x installations somewhere, can you try the
same with those? I don't think something's changed significantly in
this area since Emacs 24.1, where bidirectional display slowed such
long lines some more.
I should explain that I configured Emacs to visit that file in Rmail mode.
Try it that way.
I tried visiting it in 24.3.50.1 from May 1 2013.
Scrolling the file in Rmail mode is much faster in that version
than in the current version. So is C-n.
With find-file-literally it is almost instantaneous
in both 24.3.50.1 and the current version.
--
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Tue, 06 May 2014 12:48:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 17404 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 06 May 2014 07:42:47 -0400
> From: Richard Stallman <rms <at> gnu.org>
> CC: 17404 <at> debbugs.gnu.org
>
> I should explain that I configured Emacs to visit that file in Rmail mode.
> Try it that way.
I did. I used "C-u M-x rmail RET foo2.mail RET" in "emacs -Q". Does
that reproduce the problem on your system?
What about "emacs -nw" -- do you see the same slowdown there? Or is
the problem limited to the GUI sessions?
> I tried visiting it in 24.3.50.1 from May 1 2013.
Thanks, I'll try to see which change(s) could be responsible, but a
year is a lot in Emacs development, so if you could reduce the range,
it would help.
> Scrolling the file in Rmail mode is much faster in that version
> than in the current version. So is C-n.
How much more faster? Can you estimate the slowdown quantitatively?
> With find-file-literally it is almost instantaneous
> in both 24.3.50.1 and the current version.
find-file-literally disables bidirectional display, so it will always
result in faster redisplay.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Tue, 06 May 2014 13:22:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 17404 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 06 May 2014 15:47:25 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 17404 <at> debbugs.gnu.org
>
> > Date: Tue, 06 May 2014 07:42:47 -0400
> > From: Richard Stallman <rms <at> gnu.org>
> > CC: 17404 <at> debbugs.gnu.org
> >
> > I should explain that I configured Emacs to visit that file in Rmail mode.
> > Try it that way.
>
> I did. I used "C-u M-x rmail RET foo2.mail RET" in "emacs -Q". Does
> that reproduce the problem on your system?
>
> What about "emacs -nw" -- do you see the same slowdown there? Or is
> the problem limited to the GUI sessions?
Also, could you please try profiling Emacs and reporting the results?
Like this:
M-x load-file RET simple.el RET
C-u M-x rmail RET foo2.mail RET
C-s GNU Emacs
C-f
M-x profiler-start RET RET
Now press and hold C-n for 5 seconds, then release C-n and type
M-x profiler-report RET
In the buffer with the profile, please type "C-u RET" on every line
that has a "+" to its left, to completely expand the profile. Then
please post the result.
Here's my profile:
- command-execute 159 100%
- let 159 100%
- if 159 100%
- let 159 100%
- cond 159 100%
- prog1 159 100%
- call-interactively 159 100%
- next-line 150 94%
- if 150 94%
- if 150 94%
- condition-case 150 94%
- line-move 150 94%
- if 150 94%
- if 150 94%
- if 150 94%
- prog1 150 94%
- line-move-visual 103 64%
- let 103 64%
- or 99 62%
- and 99 62%
- or 99 62%
- and 99 62%
>= 99 62%
- if 4 2%
let 4 2%
let 47 29%
- list 9 5%
- read-extended-command 9 5%
- let 9 5%
- unwind-protect 9 5%
- progn 9 5%
- completing-read 9 5%
- completing-read-default 9 5%
read-from-minibuffer 9 5%
- ... 0 0%
Automatic GC 0 0%
This seems to indicate that line-move and line-move-visual take most
of the time. If you get a similar result, then please try replacing
these 2 functions with their code from May 2013, and see if that makes
the slowdown go away.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Wed, 07 May 2014 14:03:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 17404 <at> debbugs.gnu.org (full text, mbox):
[[[ 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 did. I used "C-u M-x rmail RET foo2.mail RET" in "emacs -Q". Does
that reproduce the problem on your system?
Yes.
What about "emacs -nw" -- do you see the same slowdown there? Or is
the problem limited to the GUI sessions?
I am always using it in a terminal. It didn't occur
to me that that made a difference to the scrolling.
> Scrolling the file in Rmail mode is much faster in that version
> than in the current version. So is C-n.
How much more faster? Can you estimate the slowdown quantitatively?
I tried it again now in several versions, and it is much faster now
than it was before. I don't understand why the problem happened and
then disappeared, but it has. For now, please forget it.
--
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17404; Package
emacs.
(Wed, 07 May 2014 15:26:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 17404 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 07 May 2014 10:02:38 -0400
> From: Richard Stallman <rms <at> gnu.org>
> CC: 17404 <at> debbugs.gnu.org
>
> What about "emacs -nw" -- do you see the same slowdown there? Or is
> the problem limited to the GUI sessions?
>
> I am always using it in a terminal. It didn't occur
> to me that that made a difference to the scrolling.
It makes a huge difference. If this happens on a TTY, I have no idea
what could have caused it.
> I tried it again now in several versions, and it is much faster now
> than it was before. I don't understand why the problem happened and
> then disappeared, but it has. For now, please forget it.
OK, thanks. Let's keep this bug open for a while, in case the problem
comes back. If it does, please use the profiler to produce the
profile, because I'm totally clueless now.
bug closed, send any further explanations to
17404 <at> debbugs.gnu.org and rms <at> gnu.org
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sat, 26 Dec 2015 15:18:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 24 Jan 2016 12:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 206 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.