bug#26051: 25.1; overlays may make emacs very slow

[Eli Zaretskii <eliz@gnu.org>]

> From: ynyaaa@gmail.com
> Cc: 26051@debbugs.gnu.org
> Date: Sat, 11 Mar 2017 13:22:48 +0900
> 
> I don't know what characters are neutral.

(I should have said "neutral or weak", sorry.)

You can find out this property of a character like this:

  M-: (get-char-code-property CHAR 'bidi-class) RET

where CHAR is the character in question, e.g. ?@ for your first
example below.  You can find more information about bidirectional
character types here:

  http://unicode.org/reports/tr9/#Bidirectional_Character_Types

Any value except L or R from the above expression means the character
doesn't have a strong directionality, which requires the display
engine to look for directional context needed for correct rendering of
the text.  And since your buffer also has no empty lines, looking for
the beginning of a paragraph is also very time consuming.  Lots of
overlays just make this preposterously slow rather than merely
sluggish, because the built-in fallbacks are tuned for the "normal"
use cases, where the number of overlays is much lower.

> The form above take a few seconds.
> I tried some characters instead of 'a'. Each of them take long time.
>   "@%d\n"
>   "?%d\n"
>   "\u00E1%d\n" ;; LATIN SMALL LETTER A WITH ACUTE
>   "\u3042%d\n" ;; HIRAGANA LETTER A
>   "\u4E00%d\n" ;; CJK IDEOGRAPH-4E00
>   "\uFF41%d\n" ;; FULLWIDTH LATIN SMALL LETTER A

What I see here, with all of the above except the first two, is that
what takes a long time is for the code to run; once I see "Done" in
the echo area, redisplay takes less than a second.

That is in contrast to the original example, and the first 2 above,
where "Done" is seen very quickly, and redisplay takes a very long
time.