bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

[Richard Copley]

Recipe from 'emacs -Q':
  M-: 3072 RET

This has the result of echoing "3072 (#o6000, #xc00)", but there's a
pause of around 8 seconds before the result is echoed. The long wait
is the bug I'm reporting.

I peeked at what was going on using Process Monitor. 11536 times, Emacs
successfully opened one of the 112 '.NLS' (codepage mapping?) files in
my C:\Windows\System32 folder. 2096 times, it opened one of 222 font
files in C:\Windows\Fonts. (I surmise it is searching for a font that
has a glyph for #xc00.)

Forgive me if this is hopelessly naive, but as we're only looking for
one {character or whatever}, is there room to optimize by memoizing
the corresponding {whatever} in each codepage, and using it while we're
searching the font files? (I don't know if it's worth it. I can't see
using Process Monitor how much time is spent reading '.NLS' files.)

This seems to be present in both the emacs-25 and master branches.

In GNU Emacs 25.0.95.1 (x86_64-w64-mingw32)
 of 2016-07-09 built on MACHINE
Repository revision: aac62a67dde02f086ae495edbc12a5046143812a
Windowing system distributor 'Microsoft Corp.', version 10.0.10586
Configured using:
 'configure --prefix /C/emacs/emacs-20160709-145855 --with-modules
 --without-imagemagick --disable-dependency-tracking
 --enable-locallisppath=%emacs_dir%/../site-lisp CFLAGS=-O3
 CPPFLAGS=-D_WIN32_WINNT=_WIN32_WINNT_WIN7'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
3072 (#o6000, #xc00)

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify dbusbind w32
multi-tty make-network-process emacs)

Memory information:
((conses 16 89840 9802)
 (symbols 56 19836 0)
 (miscs 48 47 120)
 (strings 32 16089 4464)
 (string-bytes 1 438933)
 (vectors 16 12344)
 (vector-slots 8 498616 20827)
 (floats 8 162 75)
 (intervals 56 397 1030)
 (buffers 976 20))

bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

[Noam Postavsky]

On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley@gmail.com> wrote:
> Recipe from 'emacs -Q':
>   M-: 3072 RET
>
> This has the result of echoing "3072 (#o6000, #xc00)", but there's a
> pause of around 8 seconds before the result is echoed. The long wait
> is the bug I'm reporting.

Maybe a dup of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21131

bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

[Stephen Berman]

On Sat, 9 Jul 2016 17:37:23 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley@gmail.com> wrote:
>> Recipe from 'emacs -Q':
>>   M-: 3072 RET
>>
>> This has the result of echoing "3072 (#o6000, #xc00)", but there's a
>> pause of around 8 seconds before the result is echoed. The long wait
>> is the bug I'm reporting.
>
> Maybe a dup of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21131

And of bug#16828.

Steve Berman

bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

[npostavs]

forcemerge 23930 16828
quit

Stephen Berman <stephen.berman@gmx.net> writes:

> On Sat, 9 Jul 2016 17:37:23 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:
>
>> On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley@gmail.com> wrote:
>>> Recipe from 'emacs -Q':
>>>   M-: 3072 RET
>>>
>>> This has the result of echoing "3072 (#o6000, #xc00)", but there's a
>>> pause of around 8 seconds before the result is echoed. The long wait
>>> is the bug I'm reporting.
>>
>> Maybe a dup of http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21131
>
> And of bug#16828.

Hah, which I must have looked at before, because I merged it with #19023.

bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Sat, 9 Jul 2016 22:32:43 +0100
> 
> Recipe from 'emacs -Q':
>   M-: 3072 RET
> 
> This has the result of echoing "3072 (#o6000, #xc00)", but there's a
> pause of around 8 seconds before the result is echoed. The long wait
> is the bug I'm reporting.

It looks for a font to display the codepoint.

> Forgive me if this is hopelessly naive, but as we're only looking for
> one {character or whatever}, is there room to optimize by memoizing
> the corresponding {whatever} in each codepage, and using it while we're
> searching the font files?

It's Windows that does this, not us.  Emacs just tries all the fonts
it can, looking for the character, until it gives up.