* bug#14838: 24.3.50; repeating next-line or previous-line is broken
@ 2013-07-10 21:29 Stephen Berman
2013-07-11 2:51 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Berman @ 2013-07-10 21:29 UTC (permalink / raw)
To: 14838
Starting with revision 113314, I observe the following:
0. emacs -Q
1. C-h n to visit NEWS
2. Type C-n and hold the keys down to repeatedly move point down one line.
At around line 250, the motion gets jerky and then appears to stop, and
the cursor disappears. After releasing the keys (but with a delay of
maybe a second or longer, perhaps depending on how long they were held
down), the cursor reappears on a line further down (which one seems to
depend on how long the keys were held down). Subsequently holding down
C-n or C-p makes the cursor vanish and motion stop almost immediately,
until the keys are released. The same thing happens if, after step 1
above, I type M-> and then hold down C-p (the stop seems to happen a bit
later, maybe after moving up about 300 lines).
With the revision 113360 (this one), the misbehavior begins almost
immediately with C-n, though with C-p it appears to be the same as
above.
When the motion starts getting jerky, my CPU load starts shooting up,
and hits 90%+ when the cursor disappears and motion stops, and stays at
that load until the cursor reappears at the new location.
My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of
1.8GHz. In addition to the following system information, my desktop
environment is KDE 4.9.5. My default font with emacs -Q is
xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
In GNU Emacs 24.3.50.12 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
of 2013-07-10 on rosalinde
Bzr revision: 113360 eliz@gnu.org-20130710161817-qw8stt9m23a285vy
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description: openSUSE 12.2 (x86_64)
Configured using:
`configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
Important settings:
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: @im=local
locale-coding-system: utf-8-unix
default enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-10 21:29 bug#14838: 24.3.50; repeating next-line or previous-line is broken Stephen Berman
@ 2013-07-11 2:51 ` Eli Zaretskii
2013-07-11 10:04 ` Stephen Berman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-11 2:51 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Wed, 10 Jul 2013 23:29:12 +0200
>
> Starting with revision 113314, I observe the following:
>
> 0. emacs -Q
> 1. C-h n to visit NEWS
> 2. Type C-n and hold the keys down to repeatedly move point down one line.
>
> At around line 250, the motion gets jerky and then appears to stop, and
> the cursor disappears. After releasing the keys (but with a delay of
> maybe a second or longer, perhaps depending on how long they were held
> down), the cursor reappears on a line further down (which one seems to
> depend on how long the keys were held down). Subsequently holding down
> C-n or C-p makes the cursor vanish and motion stop almost immediately,
> until the keys are released. The same thing happens if, after step 1
> above, I type M-> and then hold down C-p (the stop seems to happen a bit
> later, maybe after moving up about 300 lines).
>
> With the revision 113360 (this one), the misbehavior begins almost
> immediately with C-n, though with C-p it appears to be the same as
> above.
>
> When the motion starts getting jerky, my CPU load starts shooting up,
> and hits 90%+ when the cursor disappears and motion stops, and stays at
> that load until the cursor reappears at the new location.
>
> My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of
> 1.8GHz. In addition to the following system information, my desktop
> environment is KDE 4.9.5. My default font with emacs -Q is
> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
Does using a different font change anything?
To see which function takes most of the time, please use
profiler-start, press C-n, then after you see CPU load for some time,
invoke profiler-report. It is best to do that after manually loading
simple.el in source form.
Also, apply the patch I sent in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14836#8 and post the
contents of *Messages* after leaning on C-n for some time in this
situation.
I also asked to try reducing the keyboard auto-repeat rate, and see if
that makes any difference.
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 2:51 ` Eli Zaretskii
@ 2013-07-11 10:04 ` Stephen Berman
2013-07-11 15:59 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Berman @ 2013-07-11 10:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14838
On Thu, 11 Jul 2013 05:51:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Wed, 10 Jul 2013 23:29:12 +0200
>>
>> Starting with revision 113314, I observe the following:
>>
>> 0. emacs -Q
>> 1. C-h n to visit NEWS
>> 2. Type C-n and hold the keys down to repeatedly move point down one line.
>>
>> At around line 250, the motion gets jerky and then appears to stop, and
>> the cursor disappears. After releasing the keys (but with a delay of
>> maybe a second or longer, perhaps depending on how long they were held
>> down), the cursor reappears on a line further down (which one seems to
>> depend on how long the keys were held down). Subsequently holding down
>> C-n or C-p makes the cursor vanish and motion stop almost immediately,
>> until the keys are released. The same thing happens if, after step 1
>> above, I type M-> and then hold down C-p (the stop seems to happen a bit
>> later, maybe after moving up about 300 lines).
>>
>> With the revision 113360 (this one), the misbehavior begins almost
>> immediately with C-n, though with C-p it appears to be the same as
>> above.
>>
>> When the motion starts getting jerky, my CPU load starts shooting up,
>> and hits 90%+ when the cursor disappears and motion stops, and stays at
>> that load until the cursor reappears at the new location.
>>
>> My processor is an AMD Sempron 3400+ (64bit) with a maximum speed of
>> 1.8GHz. In addition to the following system information, my desktop
>> environment is KDE 4.9.5. My default font with emacs -Q is
>> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1
>
> Does using a different font change anything?
Yes. First, I found out that the problems I observed do not happen when
I repeat exactly the above recipe after having removed my ~/.Xresources
file and logged in again. That file contains this:
Emacs.FontBackend: xft
Emacs.Font: DejaVu Sans Mono-9
! ---------[ xft ] ---------
Xft*antialias: true
Xft*autohint: true
Without this, when I start Emacs with -Q, the font is still the one I
reported above, but now holding down C-n in NEWS works fine. I don't
understand why, since I thought -Q means no X resources are read.
When I start Emacs with my init file but without the .Xresources file, I
also don't observe the problem with C-n. In my initializations, I have
the font DejaVu Sans Mono-9 set as default in a custom theme loaded from
my init file (I've been using the .Xresources file since long before
creating the them, and didn't try removing till now). So without the
.Xresources file, I have no problem using C-n with this font, but with
the above .Xresources, the problem occurs with this font.
If I start Emacs with -q, the font used is now this:
x:-sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1
Also with this font I see no problem when holding down C-n. Likewise
starting with my initializations but removing DejaVu from the custom
them, so with the -sony-fixed-medium-r-normal- font (which apparently
comes from /usr/share/X11/app-defaults/Emacs).
However, when I switch the default font (using the Options menu) to
Adobe Courier, which starting with -Q is this:
xft:-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1
and repeat the above recipe, now I do observe the problem. This also
happens with -q and with my initializations, using Adobe Courier.
> To see which function takes most of the time, please use
> profiler-start, press C-n, then after you see CPU load for some time,
> invoke profiler-report. It is best to do that after manually loading
> simple.el in source form.
I started Emacs like this:
emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el
switched the default font to Adobe Courier as described above and then
followed your instructions; here is the report:
+ call-interactively 6758 29%
+ next-line 6059 26%
+ if 5176 22%
+ line-move 3875 16%
+ command-execute 522 2%
Automatic GC 445 1%
+ let 86 0%
+ redisplay_internal (C function) 35 0%
+ prog1 26 0%
+ read-from-minibuffer 24 0%
+ find-file-noselect 19 0%
+ run-hooks 18 0%
+ condition-case 16 0%
+ cond 12 0%
+ view-file 8 0%
+ mapc 4 0%
+ list 4 0%
+ read-extended-command 4 0%
+ vc-mode-line 3 0%
+ line-move-visual 3 0%
+ file-truename 2 0%
+ vc-find-file-hook 2 0%
+ vc-backend 2 0%
+ after-find-file 2 0%
+ completing-read 2 0%
+ let* 1 0%
+ view-emacs-news 1 0%
+ find-file-noselect-1 1 0%
+ vc-call-backend 1 0%
internal-timer-start-idle 1 0%
+ and 1 0%
> Also, apply the patch I sent in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14836#8 and post the
> contents of *Messages* after leaning on C-n for some time in this
> situation.
I did this, started Emacs -Q again as above, switched the default font
to Adobe Courier, and ran my recipe. *Message* consists of these lines:
For information about GNU Emacs and the GNU system, type C-h C-a.
bzr/emacs/quickfixes/lisp/simple.el: `with-wrapper-hook' is an obsolete macro (as of 24.4); use a <foo>-function variable modified by add-function.
View mode: type C-h for help, h for commands, q to quit.
followed by exactly 175 repetitions of these two lines (I used `M-x
occur' to make sure they were all identical):
vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
2
and nothing else.
> I also asked to try reducing the keyboard auto-repeat rate, and see if
> that makes any difference.
The default rate in my setup is 25 repeats/s. I lowered it to 15 and
repeated the above experiment, and the problem again occurs, but starts
later, around line 300. Then I lowered the repeat rate to 10, which is
annoyingly slow, and here too the problem occurs, starting around line
500.
Steve Berman
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 10:04 ` Stephen Berman
@ 2013-07-11 15:59 ` Eli Zaretskii
2013-07-11 18:51 ` Stephen Berman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-11 15:59 UTC (permalink / raw)
To: Stephen Berman, Jan Djärv; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 14838@debbugs.gnu.org
> Date: Thu, 11 Jul 2013 12:04:07 +0200
>
> Yes. First, I found out that the problems I observed do not happen when
> I repeat exactly the above recipe after having removed my ~/.Xresources
> file and logged in again. That file contains this:
>
> Emacs.FontBackend: xft
> Emacs.Font: DejaVu Sans Mono-9
>
> ! ---------[ xft ] ---------
> Xft*antialias: true
> Xft*autohint: true
>
> Without this, when I start Emacs with -Q, the font is still the one I
> reported above, but now holding down C-n in NEWS works fine. I don't
> understand why, since I thought -Q means no X resources are read.
It should. Is inhibit-x-resources set when you invoke with -Q?
Maybe the fact that X resources matter is a GTK thing? Just
guessing. Jan, could you please comment on this?
> When I start Emacs with my init file but without the .Xresources file, I
> also don't observe the problem with C-n. In my initializations, I have
> the font DejaVu Sans Mono-9 set as default in a custom theme loaded from
> my init file (I've been using the .Xresources file since long before
> creating the them, and didn't try removing till now). So without the
> .Xresources file, I have no problem using C-n with this font, but with
> the above .Xresources, the problem occurs with this font.
FWIW, I tried such a font as well (but without anti-aliasing), and
didn't see any problem.
> I started Emacs like this:
>
> emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el
>
> switched the default font to Adobe Courier as described above and then
> followed your instructions; here is the report:
>
> + call-interactively 6758 29%
> + next-line 6059 26%
> + if 5176 22%
> + line-move 3875 16%
> + command-execute 522 2%
> Automatic GC 445 1%
> + let 86 0%
> + redisplay_internal (C function) 35 0%
> + prog1 26 0%
> + read-from-minibuffer 24 0%
> + find-file-noselect 19 0%
> + run-hooks 18 0%
> + condition-case 16 0%
> + cond 12 0%
> + view-file 8 0%
> + mapc 4 0%
> + list 4 0%
> + read-extended-command 4 0%
> + vc-mode-line 3 0%
> + line-move-visual 3 0%
> + file-truename 2 0%
> + vc-find-file-hook 2 0%
> + vc-backend 2 0%
> + after-find-file 2 0%
> + completing-read 2 0%
> + let* 1 0%
> + view-emacs-news 1 0%
> + find-file-noselect-1 1 0%
> + vc-call-backend 1 0%
> internal-timer-start-idle 1 0%
> + and 1 0%
What do you see if you completely expand the profile? Do you see
line-move-partial anywhere in the profile? That's the only function
where I made significant changes in the offending revisions, so if
it's not high in the profile, I don't know what to think.
> followed by exactly 175 repetitions of these two lines (I used `M-x
> occur' to make sure they were all identical):
>
> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
> 2
>
> and nothing else.
The "py 0" part is very strange. "py" is the vertical coordinate of
point in screen line units. Since this was with C-n, I expect py
never to be less than half the screen height, which is 16. How come
it is zero, i.e. point is in the first line? Can you step through
line-move-partial in Edebug and see what is going on there?
> > I also asked to try reducing the keyboard auto-repeat rate, and see if
> > that makes any difference.
>
> The default rate in my setup is 25 repeats/s. I lowered it to 15 and
> repeated the above experiment, and the problem again occurs, but starts
> later, around line 300. Then I lowered the repeat rate to 10, which is
> annoyingly slow, and here too the problem occurs, starting around line
> 500.
This is consistent with the high CPU load you see. But I'd be damned
if I understand what is causing that CPU load, or why it happens with
some fonts, but not others.
Btw, do you have any local changes in your builds?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 15:59 ` Eli Zaretskii
@ 2013-07-11 18:51 ` Stephen Berman
2013-07-11 19:16 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Berman @ 2013-07-11 18:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14838
On Thu, 11 Jul 2013 18:59:14 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 14838@debbugs.gnu.org
>> Date: Thu, 11 Jul 2013 12:04:07 +0200
>>
>> Yes. First, I found out that the problems I observed do not happen when
>> I repeat exactly the above recipe after having removed my ~/.Xresources
>> file and logged in again. That file contains this:
>>
>> Emacs.FontBackend: xft
>> Emacs.Font: DejaVu Sans Mono-9
>>
>> ! ---------[ xft ] ---------
>> Xft*antialias: true
>> Xft*autohint: true
>>
>> Without this, when I start Emacs with -Q, the font is still the one I
>> reported above, but now holding down C-n in NEWS works fine. I don't
>> understand why, since I thought -Q means no X resources are read.
>
> It should. Is inhibit-x-resources set when you invoke with -Q?
Yes, its value is t.
> Maybe the fact that X resources matter is a GTK thing? Just
> guessing. Jan, could you please comment on this?
>
>> When I start Emacs with my init file but without the .Xresources file, I
>> also don't observe the problem with C-n. In my initializations, I have
>> the font DejaVu Sans Mono-9 set as default in a custom theme loaded from
>> my init file (I've been using the .Xresources file since long before
>> creating the them, and didn't try removing till now). So without the
>> .Xresources file, I have no problem using C-n with this font, but with
>> the above .Xresources, the problem occurs with this font.
>
> FWIW, I tried such a font as well (but without anti-aliasing), and
> didn't see any problem.
>
>> I started Emacs like this:
>>
>> emacs -Q -l ~/bzr/emacs/quickfixes/lisp/simple.el
>>
>> switched the default font to Adobe Courier as described above and then
>> followed your instructions; here is the report:
>>
>> + call-interactively 6758 29%
>> + next-line 6059 26%
>> + if 5176 22%
>> + line-move 3875 16%
>> + command-execute 522 2%
>> Automatic GC 445 1%
>> + let 86 0%
>> + redisplay_internal (C function) 35 0%
>> + prog1 26 0%
>> + read-from-minibuffer 24 0%
>> + find-file-noselect 19 0%
>> + run-hooks 18 0%
>> + condition-case 16 0%
>> + cond 12 0%
>> + view-file 8 0%
>> + mapc 4 0%
>> + list 4 0%
>> + read-extended-command 4 0%
>> + vc-mode-line 3 0%
>> + line-move-visual 3 0%
>> + file-truename 2 0%
>> + vc-find-file-hook 2 0%
>> + vc-backend 2 0%
>> + after-find-file 2 0%
>> + completing-read 2 0%
>> + let* 1 0%
>> + view-emacs-news 1 0%
>> + find-file-noselect-1 1 0%
>> + vc-call-backend 1 0%
>> internal-timer-start-idle 1 0%
>> + and 1 0%
>
> What do you see if you completely expand the profile? Do you see
> line-move-partial anywhere in the profile? That's the only function
> where I made significant changes in the offending revisions, so if
> it's not high in the profile, I don't know what to think.
Here are the top 200 lines of another profile (not identical to the one
I posted previously, but similar), which account for 99% of the CPU
time. Is this saying that 70% of CPU time is spent in line-move-partial
(and 82% in aref)?
- call-interactively 7225 30%
- next-line 7225 30%
- if 7225 30%
- if 7225 30%
- condition-case 7225 30%
- line-move 7225 30%
- if 7225 30%
- if 7225 30%
- if 5398 22%
- prog1 5398 22%
- let 5397 22%
- default-line-height 5397 22%
- let 5397 22%
- default-font-height 5397 22%
- cond 5397 22%
aref 5396 22%
display-multi-font 1 0%
- line-move-visual 1 0%
- let 1 0%
- if 1 0%
- let 1 0%
- posn-at-point 1 0%
eval 1 0%
- and 1827 7%
- line-move-partial 1827 7%
- if 1827 7%
- let* 1827 7%
- if 1801 7%
- progn 1801 7%
- if 1799 7%
let 1795 7%
if 3 0%
and 1 0%
- setq 2 0%
or 2 0%
- default-line-height 21 0%
- let 21 0%
- if 21 0%
or 20 0%
display-graphic-p 1 0%
- window-screen-lines 5 0%
- let 5 0%
- default-line-height 3 0%
let 3 0%
- / 2 0%
* 2 0%
- next-line 6340 26%
- if 6340 26%
- if 6340 26%
- condition-case 6340 26%
- line-move 6340 26%
- if 6340 26%
- if 6340 26%
- and 6247 25%
- line-move-partial 6247 25%
- if 6247 25%
- let* 6247 25%
- default-line-height 5351 22%
- let 5351 22%
- default-font-height 5350 22%
- cond 5350 22%
aref 5348 22%
display-multi-font 2 0%
- if 1 0%
- display-graphic-p 1 0%
framep-on-display 1 0%
- if 891 3%
- progn 891 3%
- setq 888 3%
- or 888 3%
let 888 3%
- if 3 0%
- let 3 0%
setq 2 0%
pos-visible-in-win 1 0%
- window-screen-lines 5 0%
- let 5 0%
- default-line-height 5 0%
- let 5 0%
if 4 0%
default-font-heigh 1 0%
- if 93 0%
- prog1 93 0%
- line-move-visual 89 0%
- let 89 0%
- or 89 0%
- and 89 0%
- or 89 0%
- and 89 0%
>= 89 0%
- let 4 0%
- default-line-height 4 0%
- let 4 0%
- default-font-height 4 0%
- cond 4 0%
- aref 2 0%
font-info 2 0%
- display-multi-font-p 2 0%
framep-on-display 2 0%
- if 5387 22%
- condition-case 5344 22%
- line-move 5344 22%
- if 5344 22%
- if 5344 22%
- and 5342 22%
- line-move-partial 5342 22%
- if 5342 22%
- let* 5342 22%
- window-screen-lines 5311 22%
- let 5311 22%
- default-line-height 5311 22%
- let 5311 22%
- default-font-height 5311 22%
- cond 5311 22%
aref 5310 22%
display-multi-font 1 0%
- if 31 0%
- progn 31 0%
- if 23 0%
- let 23 0%
- pos-visible-in-window- 23 0%
- eval 23 0%
if 21 0%
unless 1 0%
mode-line-eol-desc 1 0%
- setq 6 0%
- or 6 0%
- let 6 0%
- posn-at-point 4 0%
eval 3 0%
file-remote-p 1 0%
- if 2 0%
cdr 2 0%
- cond 2 0%
- and 2 0%
- or 2 0%
- < 2 0%
setq 2 0%
- if 2 0%
- prog1 2 0%
- line-move-visual 2 0%
- let 2 0%
- or 2 0%
- and 2 0%
- or 2 0%
- and 2 0%
- >= 2 0%
- vertical-motion 2 0%
jit-lock-function 2 0%
- if 43 0%
- condition-case 43 0%
- line-move 43 0%
- if 43 0%
- if 43 0%
- and 43 0%
- line-move-partial 43 0%
- if 43 0%
- let* 43 0%
- window-screen-lines 22 0%
- let 22 0%
- default-line-height 22 0%
- let 22 0%
- if 21 0%
or 20 0%
display-graphic-p 1 0%
- default-font-height 1 0%
cond 1 0%
- if 15 0%
- progn 15 0%
- if 9 0%
- let 9 0%
- pos-visible-in-windo 9 0%
file-remote-p 6 0%
eval 3 0%
- setq 6 0%
- or 6 0%
- let 6 0%
posn-at-point 5 0%
setq 1 0%
- default-line-height 6 0%
- let 6 0%
- default-font-height 6 0%
- cond 6 0%
- aref 6 0%
font-info 6 0%
- line-move 4084 16%
- if 4084 16%
- if 4084 16%
- and 4084 16%
- line-move-partial 4084 16%
- if 4084 16%
- let* 4084 16%
- if 4084 16%
- progn 4084 16%
- if 4084 16%
- if 4083 16%
- and 4083 16%
- >= 4083 16%
- default-font-height 4083 16%
- cond 4083 16%
aref 4083 16%
>> followed by exactly 175 repetitions of these two lines (I used `M-x
>> occur' to make sure they were all identical):
>>
>> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
>> 2
>>
>> and nothing else.
>
> The "py 0" part is very strange. "py" is the vertical coordinate of
> point in screen line units. Since this was with C-n, I expect py
> never to be less than half the screen height, which is 16. How come
> it is zero, i.e. point is in the first line? Can you step through
> line-move-partial in Edebug and see what is going on there?
If I instrument line-move-partial and type `C-n', I see py = 0 on the
first line and it increases by 1 on each subsequent line. I have no
idea why *Messages* only showed a value of 0 for py; could it be that
the messages were overwritten when the CPU load hit 90%? Is it possible
to make Edebug break execution only when that load level occurs?
>> > I also asked to try reducing the keyboard auto-repeat rate, and see if
>> > that makes any difference.
>>
>> The default rate in my setup is 25 repeats/s. I lowered it to 15 and
>> repeated the above experiment, and the problem again occurs, but starts
>> later, around line 300. Then I lowered the repeat rate to 10, which is
>> annoyingly slow, and here too the problem occurs, starting around line
>> 500.
>
> This is consistent with the high CPU load you see. But I'd be damned
> if I understand what is causing that CPU load, or why it happens with
> some fonts, but not others.
>
> Btw, do you have any local changes in your builds?
The builds I tested for my OP were from a branch that mirrors trunk,
plus or minus the changes to simple.el from before and after revision
113314; the only changes in the build used for profiling are those you
added to simple.el from 113360 to get the messages.
Steve Berman
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 18:51 ` Stephen Berman
@ 2013-07-11 19:16 ` Eli Zaretskii
2013-07-11 20:04 ` Stephen Berman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-11 19:16 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Jan Djärv <jan.h.d@swipnet.se>, 14838@debbugs.gnu.org
> Date: Thu, 11 Jul 2013 20:51:42 +0200
>
> Here are the top 200 lines of another profile (not identical to the one
> I posted previously, but similar), which account for 99% of the CPU
> time. Is this saying that 70% of CPU time is spent in line-move-partial
> (and 82% in aref)?
I don't believe the aref part. I think the real culprit is font-info.
Let's conduct an experiment: if you modify default-font-height so that
it always just calls frame-char-height, does the problem go away?
> >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
> >> 2
> >>
> >> and nothing else.
> >
> > The "py 0" part is very strange. "py" is the vertical coordinate of
> > point in screen line units. Since this was with C-n, I expect py
> > never to be less than half the screen height, which is 16. How come
> > it is zero, i.e. point is in the first line? Can you step through
> > line-move-partial in Edebug and see what is going on there?
>
> If I instrument line-move-partial and type `C-n', I see py = 0 on the
> first line and it increases by 1 on each subsequent line. I have no
> idea why *Messages* only showed a value of 0 for py; could it be that
> the messages were overwritten when the CPU load hit 90%?
Could be, since the messages are produced as part of redisplay.
Can you show the trace messages from when the CPU is not yet 100%
busy, and Emacs can still keep up with scrolling?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 19:16 ` Eli Zaretskii
@ 2013-07-11 20:04 ` Stephen Berman
2013-07-11 20:25 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Stephen Berman @ 2013-07-11 20:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14838
On Thu, 11 Jul 2013 22:16:00 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Jan Djärv <jan.h.d@swipnet.se>, 14838@debbugs.gnu.org
>> Date: Thu, 11 Jul 2013 20:51:42 +0200
>>
>> Here are the top 200 lines of another profile (not identical to the one
>> I posted previously, but similar), which account for 99% of the CPU
>> time. Is this saying that 70% of CPU time is spent in line-move-partial
>> (and 82% in aref)?
>
> I don't believe the aref part. I think the real culprit is font-info.
> Let's conduct an experiment: if you modify default-font-height so that
> it always just calls frame-char-height, does the problem go away?
Yep, that it does. And no trace messages are emitted. So it seems some
fonts are sensitive to this distinction and others aren't. What is the
crucial difference?
>> >> vs 0 dlh 14 this nil rowh 13 rbot 1 py 0 vpos 32 last 31.0
>> >> 2
>> >>
>> >> and nothing else.
>> >
>> > The "py 0" part is very strange. "py" is the vertical coordinate of
>> > point in screen line units. Since this was with C-n, I expect py
>> > never to be less than half the screen height, which is 16. How come
>> > it is zero, i.e. point is in the first line? Can you step through
>> > line-move-partial in Edebug and see what is going on there?
>>
>> If I instrument line-move-partial and type `C-n', I see py = 0 on the
>> first line and it increases by 1 on each subsequent line. I have no
>> idea why *Messages* only showed a value of 0 for py; could it be that
>> the messages were overwritten when the CPU load hit 90%?
>
> Could be, since the messages are produced as part of redisplay.
>
> Can you show the trace messages from when the CPU is not yet 100%
> busy, and Emacs can still keep up with scrolling?
There are no trace messages while scrolling is normal; only after
redisplay stops (with >90% CPU load) and then recovers do the messages
appear, and they are all as above, with py=0. I verified this by adding
a counter to the messages, and the first message emitted, with count=1,
shows py=0, as do all subsequent (none are overwritten).
Steve Berman
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 20:04 ` Stephen Berman
@ 2013-07-11 20:25 ` Eli Zaretskii
2013-07-12 9:48 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-11 20:25 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org
> Date: Thu, 11 Jul 2013 22:04:07 +0200
>
> > I don't believe the aref part. I think the real culprit is font-info.
> > Let's conduct an experiment: if you modify default-font-height so that
> > it always just calls frame-char-height, does the problem go away?
>
> Yep, that it does. And no trace messages are emitted.
Thanks, I will come up with a change that will refrain from calling
font-info unless it's strictly necessary.
> So it seems some fonts are sensitive to this distinction and others
> aren't. What is the crucial difference?
Not sure, but I saw that the implementation of font-info actually
opens the font file, so there's probably some non-trivial processing
involved in that. And likewise for font-face -- it calls the font
back-end.
> There are no trace messages while scrolling is normal; only after
> redisplay stops (with >90% CPU load) and then recovers do the messages
> appear, and they are all as above, with py=0.
Ah, OK, now everything is clear.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-11 20:25 ` Eli Zaretskii
@ 2013-07-12 9:48 ` Eli Zaretskii
2013-07-12 10:19 ` Stephen Berman
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-12 9:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 14838, stephen.berman
> Date: Thu, 11 Jul 2013 23:25:05 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14838@debbugs.gnu.org
>
> > From: Stephen Berman <stephen.berman@gmx.net>
> > Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org
> > Date: Thu, 11 Jul 2013 22:04:07 +0200
> >
> > > I don't believe the aref part. I think the real culprit is font-info.
> > > Let's conduct an experiment: if you modify default-font-height so that
> > > it always just calls frame-char-height, does the problem go away?
> >
> > Yep, that it does. And no trace messages are emitted.
>
> Thanks, I will come up with a change that will refrain from calling
> font-info unless it's strictly necessary.
I'm unsure what test(s) to use to detect reliably the situation where
the font of the default face is different from the frame's default.
The two candidates I thought about are:
. See if face-remapping-alist is non-nil and includes an association
for the 'default' face
. Compare
(frame-parameter 'font)
with
(face-font 'default)
Regarding the 1st candidate, I'm not sure the condition will always
hold whenever the font of the default face was modified in some way.
Regarding the 2nd candidate, I'm not sure (frame-parameter 'font) will
always return a non-trivial value. Can it return nil, for example?
Any other suggestions?
Stephen, can you test both of the above in your case?
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-12 9:48 ` Eli Zaretskii
@ 2013-07-12 10:19 ` Stephen Berman
2013-07-12 10:35 ` Eli Zaretskii
2013-07-13 7:29 ` Eli Zaretskii
0 siblings, 2 replies; 13+ messages in thread
From: Stephen Berman @ 2013-07-12 10:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14838
On Fri, 12 Jul 2013 12:48:41 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 11 Jul 2013 23:25:05 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 14838@debbugs.gnu.org
>>
>> > From: Stephen Berman <stephen.berman@gmx.net>
>> > Cc: jan.h.d@swipnet.se, 14838@debbugs.gnu.org
>> > Date: Thu, 11 Jul 2013 22:04:07 +0200
>> >
>> > > I don't believe the aref part. I think the real culprit is font-info.
>> > > Let's conduct an experiment: if you modify default-font-height so that
>> > > it always just calls frame-char-height, does the problem go away?
>> >
>> > Yep, that it does. And no trace messages are emitted.
>>
>> Thanks, I will come up with a change that will refrain from calling
>> font-info unless it's strictly necessary.
>
> I'm unsure what test(s) to use to detect reliably the situation where
> the font of the default face is different from the frame's default.
> The two candidates I thought about are:
>
> . See if face-remapping-alist is non-nil and includes an association
> for the 'default' face
>
> . Compare
>
> (frame-parameter 'font)
>
> with
>
> (face-font 'default)
>
> Regarding the 1st candidate, I'm not sure the condition will always
> hold whenever the font of the default face was modified in some way.
>
> Regarding the 2nd candidate, I'm not sure (frame-parameter 'font) will
> always return a non-trivial value. Can it return nil, for example?
>
> Any other suggestions?
>
> Stephen, can you test both of the above in your case?
With emacs -Q, where the problem with holding down C-n does not happen
(when I have no ~/.Xresources file):
face-remapping-alist => nil
(frame-parameter nil 'font) =>
"-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
(face-font 'default) =>
"-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
and after setting the default font to one that does cause the problem:
face-remapping-alist => nil
(frame-parameter nil 'font) =>
"-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
(face-font 'default) =>
"-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
I guess that's not very helpful :-(
Steve Berman
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-12 10:19 ` Stephen Berman
@ 2013-07-12 10:35 ` Eli Zaretskii
2013-07-13 7:29 ` Eli Zaretskii
1 sibling, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-12 10:35 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org
> Date: Fri, 12 Jul 2013 12:19:44 +0200
>
> With emacs -Q, where the problem with holding down C-n does not happen
> (when I have no ~/.Xresources file):
>
> face-remapping-alist => nil
> (frame-parameter nil 'font) =>
> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
> (face-font 'default) =>
> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
>
> and after setting the default font to one that does cause the problem:
>
> face-remapping-alist => nil
> (frame-parameter nil 'font) =>
> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
> (face-font 'default) =>
> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
>
> I guess that's not very helpful :-(
No, it actually is very helpful. Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-12 10:19 ` Stephen Berman
2013-07-12 10:35 ` Eli Zaretskii
@ 2013-07-13 7:29 ` Eli Zaretskii
2013-07-13 13:15 ` Stephen Berman
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2013-07-13 7:29 UTC (permalink / raw)
To: Stephen Berman; +Cc: 14838
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org
> Date: Fri, 12 Jul 2013 12:19:44 +0200
>
> With emacs -Q, where the problem with holding down C-n does not happen
> (when I have no ~/.Xresources file):
>
> face-remapping-alist => nil
> (frame-parameter nil 'font) =>
> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
> (face-font 'default) =>
> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
>
> and after setting the default font to one that does cause the problem:
>
> face-remapping-alist => nil
> (frame-parameter nil 'font) =>
> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
> (face-font 'default) =>
> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
Please try trunk revision 113410 or later. If the problem with slow
scrolling is not solved by it, please tell what did I do wrong in
default-font-height. It is supposed not to call font-info in your
case.
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#14838: 24.3.50; repeating next-line or previous-line is broken
2013-07-13 7:29 ` Eli Zaretskii
@ 2013-07-13 13:15 ` Stephen Berman
0 siblings, 0 replies; 13+ messages in thread
From: Stephen Berman @ 2013-07-13 13:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 14838-done
On Sat, 13 Jul 2013 10:29:55 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 14838@debbugs.gnu.org
>> Date: Fri, 12 Jul 2013 12:19:44 +0200
>>
>> With emacs -Q, where the problem with holding down C-n does not happen
>> (when I have no ~/.Xresources file):
>>
>> face-remapping-alist => nil
>> (frame-parameter nil 'font) =>
>> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
>> (face-font 'default) =>
>> "-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1"
>>
>> and after setting the default font to one that does cause the problem:
>>
>> face-remapping-alist => nil
>> (frame-parameter nil 'font) =>
>> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
>> (face-font 'default) =>
>> "-Adobe-Adobe Courier-normal-normal-normal-*-14-*-*-*-m-90-iso10646-1"
>
> Please try trunk revision 113410 or later. If the problem with slow
> scrolling is not solved by it, please tell what did I do wrong in
> default-font-height. It is supposed not to call font-info in your
> case.
With that revision the problem is now solved, so I'm closing the bug.
FWIW, I don't see it with the ~/.Xresources file now, either (though it
remains a mystery why that was apparently also triggering the problem,
but one not worth keeping this bug open for). Thanks very much for
fixing this.
Steve Berman
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-07-13 13:15 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-10 21:29 bug#14838: 24.3.50; repeating next-line or previous-line is broken Stephen Berman
2013-07-11 2:51 ` Eli Zaretskii
2013-07-11 10:04 ` Stephen Berman
2013-07-11 15:59 ` Eli Zaretskii
2013-07-11 18:51 ` Stephen Berman
2013-07-11 19:16 ` Eli Zaretskii
2013-07-11 20:04 ` Stephen Berman
2013-07-11 20:25 ` Eli Zaretskii
2013-07-12 9:48 ` Eli Zaretskii
2013-07-12 10:19 ` Stephen Berman
2013-07-12 10:35 ` Eli Zaretskii
2013-07-13 7:29 ` Eli Zaretskii
2013-07-13 13:15 ` Stephen Berman
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).