GNU bug report logs - #60810
30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw

Previous Next

To reply to this bug, email your comments to 60810 AT debbugs.gnu.org.

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

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

From: Allen Wang <allenhw1996 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
Date: Sat, 14 Jan 2023 00:07:31 -0800

[Message part 1 (text/plain, inline)]

Hi maintainers,

To reproduce, I evaluated these in the scratch buffer.

    (defun sayhi (&rest _)
      (while-no-input
        (dotimes (_ 10000000)
          (random)))
      (message "Done."))

    (add-hook 'post-command-hook 'sayhi)

After `C-x C-e`-ing the last line, I kept typing some arbitrary text at a
normal speed.

With `emacs -Q -nw`, the last character shows up pretty much immediately
after the new key is pressed (as I expect). In GUI, however, there is
significant delay. Say if I type "hello world", then maybe "h" and "e"
would show up, then nothing happens for a few seconds, then the rest would
"burst out".

I'm not sure if this is considered a "bug", so sorry if this isn't the
right place to report this. But after looking at documentation and a few
other bug reports, it sounds like people expect `while-no-input' to work in
this scenario? Also I see completion packages like Corfu and Vertico wrap
things in this macro in the post-command-hook, and despite them doing that,
auto-completion is still quite laggy for me, _only_ when in GUI. If this is
not a bug, where should I submit a feature request?

Either way, thanks for your time.

Allen

---

In GNU Emacs 30.0.50 (build 1, x86_64-apple-darwin18.7.0, NS
appkit-1671.60 Version 10.14.6 (Build 18G9323)) of 2023-01-13 built on
Allens-MacBook-Air.local
Repository revision: 99120491730c5839a5ba15ded187d481af1e71a7
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1671
System Description:  Mac OS X 10.14.6

Configured using:
'configure
CPPFLAGS=-I/usr/local/opt/curl/include
LDFLAGS=-L/usr/local/opt/curl/lib'

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XIM ZLIB

Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-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
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 37461 8829)
(symbols 48 5061 0)
(strings 32 13063 2251)
(string-bytes 1 377288)
(vectors 16 10360)
(vector-slots 8 162082 5991)
(floats 8 21 23)
(intervals 56 219 0)
(buffers 976 10))

[Message part 2 (text/html, inline)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Allen Wang <allenhw1996 <at> gmail.com>
Cc: 60810 <at> debbugs.gnu.org
Subject: Re: bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much
 slower than emacs -nw
Date: Sun, 15 Jan 2023 09:36:24 +0800

Allen Wang <allenhw1996 <at> gmail.com> writes:

> Hi maintainers,
>
> To reproduce, I evaluated these in the scratch buffer.
>
>     (defun sayhi (&rest _)
>       (while-no-input
>         (dotimes (_ 10000000)
>           (random)))
>       (message "Done."))
>
>     (add-hook 'post-command-hook 'sayhi)
>
> After `C-x C-e`-ing the last line, I kept typing some arbitrary text at a normal speed.
>
> With `emacs -Q -nw`, the last character shows up pretty much immediately after the new key is pressed (as I expect). In GUI, however, there is
> significant delay. Say if I type "hello world", then maybe "h" and "e" would show up, then nothing happens for a few seconds, then the rest
> would "burst out".
>
> I'm not sure if this is considered a "bug", so sorry if this isn't the right place to report this. But after looking at documentation and a few other
> bug reports, it sounds like people expect `while-no-input' to work in this scenario? Also I see completion packages like Corfu and Vertico wrap
> things in this macro in the post-command-hook, and despite them doing that, auto-completion is still quite laggy for me, _only_ when in GUI. If
> this is not a bug, where should I submit a feature request?

Thanks.  This problem is because the NS port does not support
interrupt-based input, because of limitations in Apple's toolkit.

This means Emacs is not notified immediately about new input while it is
executing Lisp, and instead has to periodically check every 1 second.
To decrease the amount of time between each check, make `polling-period'
smaller.  However, that will increase Emacs's CPU usage, even when idle.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: allenhw1996 <at> gmail.com, 60810 <at> debbugs.gnu.org
Subject: Re: bug#60810: 30.0.50;
 `while-no-input' in GUI(macOS) is much slower than emacs -nw
Date: Sun, 15 Jan 2023 09:08:17 +0200

> Cc: 60810 <at> debbugs.gnu.org
> Date: Sun, 15 Jan 2023 09:36:24 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Thanks.  This problem is because the NS port does not support
> interrupt-based input, because of limitations in Apple's toolkit.
> 
> This means Emacs is not notified immediately about new input while it is
> executing Lisp, and instead has to periodically check every 1 second.

Does NS use a separate thread to handle input events?  If so, could
that separate thread set quit-flag when we are under throw-on-input,
if it detects a suitable input event?  The w32 port does that, see
signal_user_input in w32fns.c.  This should allow the Lisp thread
detect that input is pending in a more timely fashion.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: allenhw1996 <at> gmail.com, 60810 <at> debbugs.gnu.org
Subject: Re: bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much
 slower than emacs -nw
Date: Sun, 15 Jan 2023 17:41:26 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> Does NS use a separate thread to handle input events?

Unfortunately not.

> If so, could that separate thread set quit-flag when we are under
> throw-on-input, if it detects a suitable input event?  The w32 port
> does that, see signal_user_input in w32fns.c.  This should allow the
> Lisp thread detect that input is pending in a more timely fashion.

I understand that approach, it's taken in the Android port as well.
Unfortunately, it cannot work because the NS port currently runs in the
same thread that Lisp runs in.

Thanks.

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

From: Allen Wang <allenhw1996 <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 60810 <at> debbugs.gnu.org
Subject: Re: bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower
 than emacs -nw
Date: Sun, 15 Jan 2023 12:48:59 -0800

[Message part 1 (text/plain, inline)]

Thank you for the quick response and the info. Sounds like this can't be
fixed easily; I'll see if polling-period works for me.

On Sun, Jan 15, 2023 at 1:41 AM Po Lu <luangruo <at> yahoo.com> wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Does NS use a separate thread to handle input events?
>
> Unfortunately not.
>
> > If so, could that separate thread set quit-flag when we are under
> > throw-on-input, if it detects a suitable input event?  The w32 port
> > does that, see signal_user_input in w32fns.c.  This should allow the
> > Lisp thread detect that input is pending in a more timely fashion.
>
> I understand that approach, it's taken in the Android port as well.
> Unfortunately, it cannot work because the NS port currently runs in the
> same thread that Lisp runs in.
>
> Thanks.
>

[Message part 2 (text/html, inline)]

Previous Next

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