moving around between cjk characters is very slow

[albert748]

thanks for your great configuration first! awsome for emacs beginner like me.

when I first try to input some chinese characters, it's very slow to moving around use C-f, C-b, M-a, M-e, especially use C-n, C-p， emacs will hang for about 1~2 seconds.

I've tried to disable all minor mode, but not working.

my emacs version is emacs 24.5

Test methods, copy chars below to a new buffer, try keys as I described:

这是使用中文输入的文字
使用的输入法是中州韵
搜狗是什么破玩意儿？我没听说过！

[purcell]

Yes, I've noticed this before with buffers which contain characters from multiple character sets. I think it's due to Emacs initializing its extended multi-language (MULE) support only when necessary, but I'm not an expert on this, so I'm not sure. In particular, I'm not aware of any way to avoid this behaviour.

[cpitclaudel]

I can reproduce it in 25.0.50, and it doesn't seem to go away, so I'm not sure about the loading MULE part. @albert748, can you try to run emacs as emacs -Q and see if it still happens? That solves it for me.

[cpitclaudel]

@albert748 Ok, so I pinpointed this in my .emacs to a line looking like the following:

(set-fontset-font fontset 'unicode (font-spec :name "Consolas") nil 'append)

Do you use something similar?

[cpitclaudel]

Ok, here's a pretty small repro. @purcell, maybe you could try it:

1. emacs -Q, go to the scratch buffer

2. Run the following snippet:

   (progn
     (dotimes (_ 3)
       (set-fontset-font t 'unicode (font-spec :name "Arial") nil 'append))
     (dotimes (_ 50)  
       (insert "日本国\n")))

3. Move around, notice that going up and down, or shift-selecting text, is horribly slow. If you don't notice anything, try replacing the 3 in there by 30.

Can you reproduce this?

Might also be interesting: I can't reproduce this in 24.3.

[cpitclaudel]

Ok, so I bisected through the 1.6k revisions that separate 24.3 from master; the culprit seems to be af1a69f4d17a482c359d98c00ef86fac835b5fac:

  Date:   Wed Apr 2 17:24:19 2014 +0400

      * font.c (font_list_entities): Do not add empty vector to font cache.
      (font_matching_entity): Likewise.  If matching entity is found, insert
      1-item vector with this entity instead of entity itself (Bug#17125).

I posted a bug report.

[bkoropoff]

@cpitclaudel I've been running in to this myself. Can you link to the emacs bug report?

[cpitclaudel]

@bkoropoff Here's the thread. Feel free to add your voice there!

[emuio]

(progn
  (dotimes (_ 3)
    (set-fontset-font t 'unicode (font-spec :name "Arial") nil 'append))
  (dotimes (_ 50)  
    (insert "日本国\n")))

@cpitclaudel I tested in 24.3/24.4/24.5 and can't reproduce this.

[cpitclaudel]

@emuio Indeed, nor could a number of people who tried on the Emacs bug tracker. Hence the thread there more or less dying away. Reverting the patch that I listed works fine for me, and it was already quite a pain to locate it, so I'm not sure if I want to spend a lot more time trying to find where the issue comes from. It could be a platform specific thing (it occurs on Linux Mint for me), and it could be due to certain fonts.

[ferfebles]

I'm having a problem with slow scrolling when using an old Windows XP VAIO laptop: it has 1.5GB RAM, and a Pentium M 1.1GHz. .
The tests have been done with Emacs 24.5.1

After disabling several modes, I realized that:

• The window area is an important factor. If you repeat the same test with different window sizes, the speed can be very different.
• The scroll speed is related to the drawing process: my XP has ClearType enabled. If I use a font that has been hinted and smoothed (*) (like Consolas) the scroll is slow, but if I use a very simple font like Courier (not Courier New, only Courier) that has no hinting or smoothing information, the performance is much much better.

The problem is that when several people is testing this, they have:

• Different operating systems, with different text rendering processes (ClearType, font smoothing, text console...)
• Different fonts (or even versions of the same font) with different hinting and smoothing information.
• Different hardware, screen resolution and Emacs windows sizes.
• Different Emacs configurations.
• And different buffer content with or without UTF8 chars.

I ended using Courier New, a True Type font that between 7 and 27 points, is only hinted, but not smoothed. I'ts the best balance between speed and image quality.

(*) Hinted can be seen as aligning the font shape to the monitor pixels, while smoothing is using the LCD/TFT RGB subpixels to provide better resolution.

[cpitclaudel]

See the emacs-dev bug thread. If you're having the same issue, then the bug is clearly identified. It comes from a commit that was introduced to fix another bug, and since that bug is deemed more important than this one, there's no desire to revert the fix. I tried to find another fix for that bug, but I can't reproduce it.

[ferfebles]

After more tests, I've realized that the area of the window was not a factor for slow scroll: I was opening the Task Manager to see the CPU% used... but the Task Manager is a special window, it's always over the other windows, you can't hide it.

When I resized the emacs window under the Task Manager window, the scroll became very very slow.

The rest about hinted and smoothed fonts seems to be right.

I've tested this:

(progn
(dotimes (_ 3)
(set-fontset-font t 'unicode (font-spec :name "Arial") nil 'append))
(dotimes (_ 50)
(insert "日本国\n")))

And in my configuration, emacs hangs for about half a second when scrolling.

I've configured these variables to get a smooth scroll with not too much CPU penalty:

              scroll-conservatively 101            ; scroll line by line
              ;; scroll-step 1                             ; smoother scroll, but too much CPU used
              auto-window-vscroll nil               ; less cpu used?
              line-spacing 0                             ; used to improve performance when computing default-line-height

[stephenwan]

I have encountered the same problem with Emacs 25.1 on Windows, not necessarily due to the same cause though. Whenever I opened a buffer containing unicode chars to edit, navigation inside the buffer becomes very sluggish.

I have found the following solution from the Emacs mailing group to be very effective.

Globally set the variable inhibit-compacting-font-caches to t

as explained by the original author

With some fonts, the cache is compacted on every GC, and GC happens
very frequently. So in your case, the answer is probably "every
cursor movement".

Ref: here

[cpitclaudel]

Also, the original cause was fixed in a commit 3 days ago :)

[purcell]

Since I never use Windows, I'm wary of committing a selective fix to this config. You should probably add something like the following to your local config:

(when (and (eq system-type 'nt) (string-equal emacs-version "25.1"))
  (setq inhibit-compacting-font-caches t))

[c0001]

Hi everyone who seem to solve this problem by set inhibit-compacting-font-caches to t:

There's much more problem from here like the friend upon said it.

I found enable the compact option can solve the minimal region with unicode character but the larger
one like buffer in describe-char's *help-mode* buffer with chosen the candidate of unicode-bmp.

Or if you call the view-hello-file, the chance you can try now 👍 .

Plattform: win10 daily updately
Emacs version: 25.2 25.3.1 26.1-rc1 27.0.50
Whether clean init: Yes
Language Environment: Both gbk and utf-8-unix