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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23930 in the body.
You can then email your comments to 23930 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Richard Copley <rcopley <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 25.0.95; "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"
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.

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))

Message #8 received at 23930 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 23930 <at> debbugs.gnu.org
Subject: Re: bug#23930: 25.0.95; "M-: 3072 RET" very slow to echo "3072
 (#o6000, #xc00)"
Date: Sat, 9 Jul 2016 17:37:23 -0400

On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley <at> 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

Message #15 received at 23930 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: Richard Copley <rcopley <at> gmail.com>, 23930 <at> debbugs.gnu.org
Subject: Re: bug#23930: 25.0.95;
 "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"
Date: Sun, 10 Jul 2016 01:16:08 +0200

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

> On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley <at> 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

Message #18 received at 23930 <at> debbugs.gnu.org (full text, mbox):

From: npostavs <at> users.sourceforge.net
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Richard Copley <rcopley <at> gmail.com>, 23930 <at> debbugs.gnu.org
Subject: Re: bug#23930: 25.0.95;
 "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"
Date: Sat, 09 Jul 2016 19:59:35 -0400

forcemerge 23930 16828
quit

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

> On Sat, 9 Jul 2016 17:37:23 -0400 Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
>
>> On Sat, Jul 9, 2016 at 5:32 PM, Richard Copley <rcopley <at> 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.

Message #23 received at 23930 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 23930 <at> debbugs.gnu.org
Subject: Re: bug#23930: 25.0.95;
 "M-: 3072 RET" very slow to echo "3072 (#o6000, #xc00)"
Date: Sun, 10 Jul 2016 05:38:36 +0300

> From: Richard Copley <rcopley <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.