bug#22519: 25.1.50; Emacs gets stuck while doing incremental search forward

[vincent.belaiche@gmail.com (Vincent Belaïche)]

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

Dear Eli,

Answers below...

Le 15/03/2016 19:11, Eli Zaretskii a écrit :
>> From: vincent.belaiche@gmail.com (Vincent Belaïche)
>> Cc: Vincent Belaïche <vincent.belaiche@gmail.com> ,
>>  22519@debbugs.gnu.org
>> Date: Tue, 15 Mar 2016 14:28:18 +0100
>>
>> Ok, I decided to make some test bench (herein attached).
>>
>> I get the following interaction:
>>
>>  $ ./emacs-bug22519.sh --fundamental no
>> -| mode: normal
>> -| latin-9=(0.588 5 0.031999999999999994)
>> -| utf-8=(111.257 146 1.3299999999999979)
>>  $ ./emacs-bug22519.sh --fundamental yes
>> -| mode: fundamental
>> -| latin-9=(0.209 0 0.0)
>> -| utf-8=(95.442 129 1.121)
>>
>> As you see, in normal mode utf-8 is 189 times slower than latin-9, and
>> in fundamental mode, it is 456 times slower.
>
> My results are in stark contrast to yours:
>
>  . with the current emacs-25 branch, an unoptimized build:
>
>     $ ./emacs-bug22519.sh --fundamental no
>     mode: normal
>     latin-9=(5.0 5 0.10899999999999999)
>     utf-8=(10.14 13 0.44)
>     $ ./emacs-bug22519.sh --fundamental yes
>     mode: fundamental
>     latin-9=(0.359 0 0.0)
>     utf-8=(2.938 4 0.126)
>
>  . with Emacs 25.0.92 pretest, compiled with -Og:
>
>     $ ./emacs-bug22519.sh --fundamental no
>     mode: normal
>     latin-9=(0.64 5 0.046)
>     utf-8=(1.953 13 0.156)
>     $ ./emacs-bug22519.sh --fundamental yes
>     mode: fundamental
>     latin-9=(0.109 0 0.0)
>     utf-8=(0.984 4 0.062)
>
> So while there is some slowdown when showing these symbols (which
> could be due to the need to load the necessary font), the slowdown is
> nowhere as dramatic as on your system.

FYI, my Emacs was generated with the following flags:

  export CPPFLAGS="$CPPFLAGS -DFOR_MSW=1 -I ${HERE_DIR}/libXpm-3.5.8/include -I ${HERE_DIR}/libXpm-3.5.8/src -L ${HERE_DIR}/libXpm-3.5.8/src"
  export CFLAGS="$CFLAGS -Og -g3 -L ${HERE_DIR}/libXpm-3.5.8/src"

>
> IOW, I still cannot reproduce the problem on my system.  I suspect
> some issue with your font configuration, but that's just a guess.

I have the same type of suspicion that it has to do with the display. Ie
some code running outside Emacs in some standard system library of
Windows API. However, there may also be some suboptimal coding in the
ways that Emacs, or some graphic library used by Emacs, interacts with
these library fuctions.

I have attached a picture of my display, as you see I have a few not
displayable characters. They are displayed with small retangles
containing the Unicode code point in 4 hexadecimal letters --- let us
call this an hexa-rectangle.

My speculation is that every time MSWindows is requested for such not
displayable character, then it spends a lot of time seeking whether this
character can be displayed in any of the supported fonts, and if not, it
spends again time making on the fly the special hexa-rectangle
characters, or maybe those hexa-rectangle bitmaps are placed in some
memory area that is not fast enough...

So, do you have also any hexa-rectangles displayed on your system ?

Maybe you could try and reproduce the problem by replacing in the file
some of the math symbols by characters that are not displayable on your
machine. E.g. you could do some `M-: (insert (string #xhhhh)) RET' with
hhhh in { FFF0, FFC0, FFD0, FFC1, FFD1, FFE7, FFC8, FFD8, FFC9, FFD9,
FFDD, FFDE, FFBF, FFDF, FFEF, 0380, 0381, 0382, 03A2, 0383, 0377, 0378,
038B, 038D}, based on taking greyed cells from page 2 of these
documents:

   http://www.unicode.org/charts/PDF/UFF00.pdf
   http://www.unicode.org/charts/PDF/U0370.pdf

Just to make it as close to my situation, it is certainly better to take
a number of different values for hhhh.

BTW, even if we end up concluding that the problem is some sort of MSW
bug, I still think that there is also something in Emacs: now the `Emacs
stuck' does not happen so often, maybe this is due to this that there
has been some MSW update meanwhile, but still it can happen after system
wake-up.

VBR,
	Vincent.



[-- Attachment #2: Sans titre.png --]
[-- Type: image/png, Size: 114580 bytes --]