[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#6364: closed (Windows: Emacs 23 slow with long lin

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#6364: closed (Windows: Emacs 23 slow with long lines and raster fonts)
Date: Fri, 29 Nov 2013 11:07:02 +0000

Your message dated Fri, 29 Nov 2013 13:05:54 +0200
with message-id <address@hidden>
and subject line Re: bug#6364: [PATCH] Use GetCharABCWidthsFloatW if 
GetGlyphOutlineW   fails.
has caused the debbugs.gnu.org bug report #6364,
regarding Windows: Emacs 23 slow with long lines and raster fonts
to be marked as done.

(If you believe you have received this mail in error, please contact

6364: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6364
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Windows: Emacs 23 slow with long lines and raster fonts Date: Sun, 06 Jun 2010 14:39:35 -0400

the Windows build of Emacs 23 is extremely slow when scrolling in a buffer
containing long lines if a bitmap font is used.

For example, scrolling though a file made of 200 lines of 1000 characters
each feels choppy.
Doing the same with a file containing very long lines (like tens of thousand characters) can make Emacs hang for seconds or minutes, making it practically

Editing files with such long lines is not absurd, various types of computer
generated files (log files, export files, dumps, ...) can have very very
long lines.

These bad performances are a regression, Emacs 21 and Emcas 22 were much
faster in the same conditions.

To illustrate this regression, and to show it's related to the use of bitmap
fonts, I've made this very simple and easy to reproduce benchmark:

I built an 8MB file containing a single line (the content of the file
doesn't matter). I opened the file in emacs, and then I hit "ESC >" to reach
the end of the buffer. I measured the time it takes for emacs to refresh
from the moment I typed the macro.

(Test setup: Athlon XP 2GHz, Windows XP SP3)

If Emacs is started with the command line "emacs -q", here are the results:

Emacs 21.3.1:    8s
Emacs 22.3.1:   14s
Emacs 23.2.1:   63s  (uniscribe backend)

Emacs 23 can be made a little faster by forcing the gdi rendering backend
with the command line "emacs -q -xrm Emacs.FontBackend:gdi":

Emacs 23.2.1:   38s  (gdi backend)

Now, if I repeat the same test using the command "emacs -q -fn Courier", to
use a bitmap font, things are getting really bad for Emacs 23:

Emacs 21.3.1:    8s  (raster font)
Emacs 22.3.1:   14s  (raster font)
Emacs 23.2.1:  515s  (raster font, gdi backend)



PS: this issue has been discussed on the emacs-devel mailing list:

--- End Message ---
--- Begin Message --- Subject: Re: bug#6364: [PATCH] Use GetCharABCWidthsFloatW if GetGlyphOutlineW fails. Date: Fri, 29 Nov 2013 13:05:54 +0200
> From: Tom Seddon <address@hidden>
> Date: Tue, 26 Nov 2013 21:50:02 +0000
> Cc: address@hidden
> On 26 Nov 2013, at 20:48, Eli Zaretskii <address@hidden> wrote:
> > OK.  So what other function(s) can be used for this purpose?
> > 
> > If there are no good alternatives, I guess we will go with
> > GetCharABCWidthsFloatW anyway, since the situation cannot become worse
> > than it is already.
> I've changed it to GetCharWidth32, which is in the list on that MSDN page - 
> see patch below. I've checked this against all bitmap fonts on my system and 
> it produces the same results (and emacs looks to behave the same, including 
> in terms of performance).

Thanks, I committed this in your name, with one change: you forgot to
initialize g_b_init_get_char_width_32_w in globals_of_w32font.

> > Btw, I used your recipe, but didn't see any significant slowdown with
> > fixed.fon (also, the file bigline.txt is missing, I just used the
> > 16384 thingy instead.
> Agh, my mistake - I should have included start-slow.el, not start-bigline.el. 
> Sorry. start-slow.el looks like this:
> (set-face-attribute 'default nil :font "fixed")
> (switch-to-buffer (find-file "usb.ids"))
> (goto-char (point-max))
> Maybe that will show up the problem? But it sounds rather like your computer 
> just doesn't suffer from this issue, for whatever reason...

I see the CPU usage decrease by half if I use Emacs with your patch
with a bitmap font, so I guess the effect is visible on my system as

Thanks.  I'm closing this bug.

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]