bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Zack Stackson]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

OS: Windows 7 x64
Monitor: 2560x1440
CPU: Intel Core i7 870 2.93 GHz
Display Adapter: AMD Radeon HD 7800
Emacs Version: emacs-24.3-bin-i386.zip. . . . . Mar 19 02:43
ftp://gnu.mirror.iweb.com/emacs/windows/
(Similar bad performance with 23.1, 23.2, 23.3, and 23.4.  Although 23.1 is
not as jumpy as 24.3)

.emacs config:
(setq scroll-step 1)


Open a text file in text-mode with 200 lines, avg line length 60
characters, max line length 70 characters, go to end of buffer, hold up
arrow to scroll up.

Result with emacs-24.3: starts at 10% cpu usage, then stays near 90-100%
cpu usage
Result with emacs-22.3: 0% cpu usage

Open a text file in text-mode with 4000 lines, avg line length 60
characters, max line length 70 characters, go to end of buffer, hold alt-v
to scroll page up.

Result with emacs-24.3: scrolling is jumpy, skipping rendering some pages,
stays near 90-100% cpu usage
Result with emacs-22.3: scrolling is smooth, renders all pages, 0-10% cpu
usage


.emacs config:
(custom-set-faces
 '(default ((t (:stipple nil :background "black" :foreground "grey"
:inverse-video nil :box nil :strike-through nil :overline nil :bold nil
:underline nil :slant normal :weight normal :height 75 :width normal
:family "sixten")))))

Open a text file in text-mode with 4000 lines, avg line length 60
characters, max line length 70 characters, go to end of buffer, hold alt-v
to scroll page up.

Result with emacs-24.3 with smaller font (6x10 from X11): scrolls one page,
then stops rendering anything (second to last page stays on the screen),
uses 100% cpu until top of buffer is reached, then starts rendering again.
Result with emacs-22.3 with smaller font (6x10 from X11): scrolling is
smooth, renders all pages, 0-50% cpu usage.


In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x 1 M-x C-y <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils warnings time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns
disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment 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 macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process w32 multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 4493 bytes --]

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Eli Zaretskii]

> Date: Sun, 15 Sep 2013 13:41:04 -0500
> From: Zack Stackson <zack.stackson@gmail.com>
> 
> OS: Windows 7 x64

Mine is XP SP3.  Not sure it matters, except perhaps the fact that you
are running a 32-bit executable on a 64-bit OS, which should have some
overhead.

> Monitor: 2560x1440

Mine is 1920x1080 (but I don't think the size matters here, unless you
are running with the frame maximized, which you didn't say).

> CPU: Intel Core i7 870 2.93 GHz

Here I have Intel Core i7-2600 at 3.40 GHz, slightly faster than
yours.

> Display Adapter: AMD Radeon HD 7800

Intel HD Graphics 2000.

> Emacs Version: emacs-24.3-bin-i386.zip. . . . . Mar 19 02:43
> ftp://gnu.mirror.iweb.com/emacs/windows/

My Emacs 24.3 binary was built by myself from the stock sources.
Again, I don't think that difference matters (if anything, my binary
should be slightly slower, since I use an old version of GCC, which
optimizes less aggressively).

> (Similar bad performance with 23.1, 23.2, 23.3, and 23.4.  Although 23.1 is
> not as jumpy as 24.3)
> 
> .emacs config:
> (setq scroll-step 1)

Is that the only thing in your .emacs?  I started "emacs -Q", then set
scroll-step to 1 manually -- do you see the same performance problem
when you do that?  If not, there's something else in your .emacs that
makes the difference.

> Open a text file in text-mode with 200 lines, avg line length 60
> characters, max line length 70 characters

Emacs 24's display performance is sensitive to the paragraph length as
well.  A paragraph start and end are defined for this purpose as empty
lines.  Is it possible that the text files you used didn't have any
empty lines at all?  If so, can you try files that do have empty
lines?  Also try setting bidi-paragraph-direction to left-to-right
(it's a per-buffer setting, so use setq-default to do that in all
buffers).

> go to end of buffer, hold up arrow to scroll up.
> 
> Result with emacs-24.3: starts at 10% cpu usage, then stays near 90-100%
> cpu usage
> Result with emacs-22.3: 0% cpu usage
> 
> Open a text file in text-mode with 4000 lines, avg line length 60
> characters, max line length 70 characters, go to end of buffer, hold alt-v
> to scroll page up.
> 
> Result with emacs-24.3: scrolling is jumpy, skipping rendering some pages,
> stays near 90-100% cpu usage
> Result with emacs-22.3: scrolling is smooth, renders all pages, 0-10% cpu
> usage

I cannot reproduce this here.  In a 17,000 line long text file,
scrolling with scroll-step = 1 from the end of the file leaves the CPU
at 2% all the time, occasionally dropping to 1%.  Emacs 23.4 stays at
1% almost all of the time with the same file, occasionally going up to
2%.

I can only see performance similar to what you report on a laptop with
a Core i3-2328M at 2.2 GHz (running Windows 7 64-bit), a much slower
machine.  I will try later on a desktop Windows 7 machine.

> .emacs config:
> (custom-set-faces
>  '(default ((t (:stipple nil :background "black" :foreground "grey"
> :inverse-video nil :box nil :strike-through nil :overline nil :bold nil
> :underline nil :slant normal :weight normal :height 75 :width normal
> :family "sixten")))))
> 
> Open a text file in text-mode with 4000 lines, avg line length 60
> characters, max line length 70 characters, go to end of buffer, hold alt-v
> to scroll page up.

With this configuration and the same 17,000 line file, I get 3% CPU
in Emacs 24.3 all the way.

> Result with emacs-24.3 with smaller font (6x10 from X11): scrolls one page,
> then stops rendering anything (second to last page stays on the screen),
> uses 100% cpu until top of buffer is reached, then starts rendering again.
> Result with emacs-22.3 with smaller font (6x10 from X11): scrolling is
> smooth, renders all pages, 0-50% cpu usage.

Couldn't try this one, since you didn't say which font you used,
exactly, and how/from where to get it installed on Windows.

Yes, Emacs 24's display is slower than that of Emacs 23, because the
former supports bidirectional scripts.  So it's not a surprise that
you see some performance degradation.  However, that degradation
should be apparent only in some rare use cases.  So the question is,
what is special in your case?

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Eli Zaretskii]

> Date: Mon, 16 Sep 2013 09:41:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15390@debbugs.gnu.org
> 
> Emacs 24's display performance is sensitive to the paragraph length as
> well.  A paragraph start and end are defined for this purpose as empty
> lines.  Is it possible that the text files you used didn't have any
> empty lines at all?  If so, can you try files that do have empty
> lines?

In addition, the characters that begin a paragraph might be of
importance.  You say "text file", so I presume that is human-readable
text, but it could also be a file with many digits and punctuation
characters -- these make redisplay work harder.

IOW, please show some representative portion(s) of the file(s) in
question, or perhaps even the entire file, if you can share it.

> I can only see performance similar to what you report on a laptop with
> a Core i3-2328M at 2.2 GHz (running Windows 7 64-bit), a much slower
> machine.  I will try later on a desktop Windows 7 machine.

Did that, and saw 20% to 30% CPU load, on a system that is powered by
a Core 2 Duo CPU, clearly much slower than yours.

Bottom line: I'm quite sure the file(s) you are using somehow hit the
display engine in its underbelly.

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Zack Stackson]

On Mon, Sep 16, 2013 at 1:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Mine is 1920x1080 (but I don't think the size matters here, unless you
> are running with the frame maximized, which you didn't say).

I am running with frame height maximized (1440px), performance with
height set to 720px is not nearly as bad.

> > .emacs config:
> > (setq scroll-step 1)
>
> Is that the only thing in your .emacs?  I started "emacs -Q", then set
> scroll-step to 1 manually -- do you see the same performance problem
> when you do that?  If not, there's something else in your .emacs that
> makes the difference.

I tested with emacs -Q and setting scroll-step to 1 manually, it is the same.

Also tested with emacs -Q and setting font to small size, page up
slowness is the same.

> Emacs 24's display performance is sensitive to the paragraph length as
> well.  A paragraph start and end are defined for this purpose as empty
> lines.  Is it possible that the text files you used didn't have any
> empty lines at all?  If so, can you try files that do have empty
> lines?  Also try setting bidi-paragraph-direction to left-to-right
> (it's a per-buffer setting, so use setq-default to do that in all
> buffers).

They did not have any empty lines, adding empty lines made it much faster.

Tried (setq bidi-paragraph-direction 'left-to-right) and (setq-default
bidi-paragraph-direction 'left-to-right), but that did not make it
faster.

> > Result with emacs-24.3 with smaller font (6x10 from X11): scrolls one page,
> > then stops rendering anything (second to last page stays on the screen),
> > uses 100% cpu until top of buffer is reached, then starts rendering again.
> > Result with emacs-22.3 with smaller font (6x10 from X11): scrolling is
> > smooth, renders all pages, 0-50% cpu usage.
>
> Couldn't try this one, since you didn't say which font you used,
> exactly, and how/from where to get it installed on Windows.

Setting font to Consolas size 68 gives similar results to the 6x10
font.  (I don't remember which program I used to convert the 6x10 X11
font to windows .fnt)

> Yes, Emacs 24's display is slower than that of Emacs 23, because the
> former supports bidirectional scripts.  So it's not a surprise that
> you see some performance degradation.  However, that degradation
> should be apparent only in some rare use cases.  So the question is,
> what is special in your case?

Emacs 23 is also slow, not as slow as 24, but not much different.
Emacs 22 is very fast, so that's the version I have been using.

Do bitmap raster fonts take more work than other fonts, maybe that's
part of it?  The font is 3kb, could I attach it?

Page up is also slow when editing files with syntax highlighting
(replace.el for example).

> Date: Mon, 16 Sep 2013 09:41:52 +0300
> From: Eli Zaretskii <eliz@gnu.org>

> In addition, the characters that begin a paragraph might be of
> importance.  You say "text file", so I presume that is human-readable
> text, but it could also be a file with many digits and punctuation
> characters -- these make redisplay work harder.

Yes, there are many numbers and punctuation, just tested with the
following repeated:

AA3036B2-CCCC DD3036E1-FFF Test text Test text Test text Test text Test

But it also happens on syntax highlighted files when using a small font.

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Eli Zaretskii]

> Date: Wed, 18 Sep 2013 22:53:36 -0500
> From: Zack Stackson <zack.stackson@gmail.com>
> Cc: 15390@debbugs.gnu.org
> 
> On Mon, Sep 16, 2013 at 1:41 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Mine is 1920x1080 (but I don't think the size matters here, unless you
> > are running with the frame maximized, which you didn't say).
> 
> I am running with frame height maximized (1440px), performance with
> height set to 720px is not nearly as bad.

Sorry, I don't understand what the last part means.  Is the 720 pixel
size what you get when you invoke Emacs as "emacs -Q"?  If not, please
let's first talk about what happens in the frame created by "emacs -Q"
and not enlarged by any command or mouse gestures.  That is what I did
to try reproducing your problems.

Or are you are saying that the performance problems are only
significant in a full-screen frame, and are imperceptible in the frame
of the size created by "emacs -Q"?  In that case, let's talk _only_
about maximized frames.

> Also tested with emacs -Q and setting font to small size, page up
> slowness is the same.

I don't think the size of the font is a factor, as long as the frame
size changes accordingly.  What matters is the amount of text Emacs
needs to scan and move when scrolling.

> > Emacs 24's display performance is sensitive to the paragraph length as
> > well.  A paragraph start and end are defined for this purpose as empty
> > lines.  Is it possible that the text files you used didn't have any
> > empty lines at all?  If so, can you try files that do have empty
> > lines?  Also try setting bidi-paragraph-direction to left-to-right
> > (it's a per-buffer setting, so use setq-default to do that in all
> > buffers).
> 
> They did not have any empty lines, adding empty lines made it much faster.

"Much faster" as in "like Emacs 23", or even faster than that?  I
would not expect the latter.

> Tried (setq bidi-paragraph-direction 'left-to-right) and (setq-default
> bidi-paragraph-direction 'left-to-right), but that did not make it
> faster.

Did you try this before or after adding empty lines?  The effect
should be significant only if there are no empty lines.

> Emacs 23 is also slow, not as slow as 24, but not much different.
> Emacs 22 is very fast, so that's the version I have been using.

Emacs 23 started using the Uniscribe font back-end.  So please try
this:

  emacs -Q -xrm Emacs.fontBackend:gdi

and see if it is much faster with the same frame geometry and font
settings, in Emacs 24.

> Do bitmap raster fonts take more work than other fonts, maybe that's
> part of it?

I don't know enough about the Windows font back-ends and drawing APIs
to answer that, sorry.

> Page up is also slow when editing files with syntax highlighting
> (replace.el for example).

Is it slow only the first time some screen-full is displayed?  That
is, if you visit a file, page down several times through it, then go
back to the beginning with C-Home, and page down again through the
same portions of the file, is the second scroll also slow, or is it
much faster?  If the latter, this is normal, as Emacs fontifies the
text on the fly when it is first displayed, and that takes time.

> > In addition, the characters that begin a paragraph might be of
> > importance.  You say "text file", so I presume that is human-readable
> > text, but it could also be a file with many digits and punctuation
> > characters -- these make redisplay work harder.
> 
> Yes, there are many numbers and punctuation, just tested with the
> following repeated:
> 
> AA3036B2-CCCC DD3036E1-FFF Test text Test text Test text Test text Test

"A", the first character of the line, is not a numeric character, so
this is not an issue in your case.

> But it also happens on syntax highlighted files when using a small font.

Syntax highlighting introduces additional factors, see above.  So I
suggest for now to try only modes that don't highlight text, or even
turn off global-font-lock-mode entirely, when testing.

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Zack Stackson]

On Thu, Sep 19, 2013 at 2:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> Or are you are saying that the performance problems are only
> significant in a full-screen frame, and are imperceptible in the frame
> of the size created by "emacs -Q"?  In that case, let's talk _only_
> about maximized frames.

The slowness is not noticeable at the default frame size, although
even at the default frame size Emacs 24 uses much more cpu to page up
than Emacs 22.

>> They did not have any empty lines, adding empty lines made it much faster.
>
> "Much faster" as in "like Emacs 23", or even faster than that?  I
> would not expect the latter.

Much faster than when there were no empty lines, but still not nearly as
fast as Emacs 22.

>> Tried (setq bidi-paragraph-direction 'left-to-right) and (setq-default
>> bidi-paragraph-direction 'left-to-right), but that did not make it
>> faster.
>
> Did you try this before or after adding empty lines?  The effect
> should be significant only if there are no empty lines.

Tried both.

>> Emacs 23 is also slow, not as slow as 24, but not much different.
>> Emacs 22 is very fast, so that's the version I have been using.
>
> Emacs 23 started using the Uniscribe font back-end.  So please try
> this:
>
>   emacs -Q -xrm Emacs.fontBackend:gdi
>
> and see if it is much faster with the same frame geometry and font
> settings, in Emacs 24.

After starting with this, how do I tell if the -xrm option is in effect?

I don't see any speed difference.

>> Page up is also slow when editing files with syntax highlighting
>> (replace.el for example).
>
> Is it slow only the first time some screen-full is displayed?  That
> is, if you visit a file, page down several times through it, then go
> back to the beginning with C-Home, and page down again through the
> same portions of the file, is the second scroll also slow, or is it
> much faster?  If the latter, this is normal, as Emacs fontifies the
> text on the fly when it is first displayed, and that takes time.

It's about the same the first time and repeated times.

The problem is worst when starting at the end of the file and doing
page up from there, even after visiting the entire file and starting
over at the end, page up starting at the end causes rendering to stop
until beginning of file is reached or I stop holding the page up key
and wait.

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Eli Zaretskii]

> Date: Mon, 23 Sep 2013 00:32:48 -0500
> From: Zack Stackson <zack.stackson@gmail.com>
> Cc: 15390@debbugs.gnu.org
> 
> On Thu, Sep 19, 2013 at 2:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > Or are you are saying that the performance problems are only
> > significant in a full-screen frame, and are imperceptible in the frame
> > of the size created by "emacs -Q"?  In that case, let's talk _only_
> > about maximized frames.
> 
> The slowness is not noticeable at the default frame size, although
> even at the default frame size Emacs 24 uses much more cpu to page up
> than Emacs 22.

I explained why CPU usage is higher ion Emacs 24: it does more work
during redisplay to support advanced features.

> > Emacs 23 started using the Uniscribe font back-end.  So please try
> > this:
> >
> >   emacs -Q -xrm Emacs.fontBackend:gdi
> >
> > and see if it is much faster with the same frame geometry and font
> > settings, in Emacs 24.
> 
> After starting with this, how do I tell if the -xrm option is in effect?

It is in effect all the time in that session.

> I don't see any speed difference.

Then the font back-end is not a factor in this.

> The problem is worst when starting at the end of the file and doing
> page up from there, even after visiting the entire file and starting
> over at the end, page up starting at the end causes rendering to stop
> until beginning of file is reached or I stop holding the page up key
> and wait.

Scrolling back is always more CPU-intensive than scrolling forward,
due to the peculiarities of the Emacs display engine implementation.

Anyway, I don't see what else I can do with this bug report.
Scrolling very large windows one line at a time is expensive, but I
cannot see such a disastrous slowdown on my machine, which is very
similar to yours.  There's some work in the development code to speed
up redisplay, maybe it will improve your experience (perhaps try the
latest development snapshot).

Sorry.

bug#15390: 24.3; scrolling in emacs,w32 uses 100% cpu

[Stefan Kangas]

tags 15390 wontfix
close 15390
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem is worst when starting at the end of the file and doing
>> page up from there, even after visiting the entire file and starting
>> over at the end, page up starting at the end causes rendering to stop
>> until beginning of file is reached or I stop holding the page up key
>> and wait.
>
> Scrolling back is always more CPU-intensive than scrolling forward,
> due to the peculiarities of the Emacs display engine implementation.
>
> Anyway, I don't see what else I can do with this bug report.
> Scrolling very large windows one line at a time is expensive, but I
> cannot see such a disastrous slowdown on my machine, which is very
> similar to yours.  There's some work in the development code to speed
> up redisplay, maybe it will improve your experience (perhaps try the
> latest development snapshot).
>
> Sorry.

That was 6 years ago and the conclusion was that there is not much we
can do here besides general work that was already undertaken to speed
up redisplay.

I'm consequently closing this as wontfix.  If that's incorrect, please
reopen the bug.

Best regards,
Stefan Kangas