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?