* bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
@ 2023-01-14 8:07 Allen Wang
2023-01-15 1:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 5+ messages in thread
From: Allen Wang @ 2023-01-14 8:07 UTC (permalink / raw)
To: 60810
[-- Attachment #1: Type: text/plain, Size: 3976 bytes --]
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))
[-- Attachment #2: Type: text/html, Size: 4652 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
2023-01-14 8:07 bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw Allen Wang
@ 2023-01-15 1:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-15 7:08 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-15 1:36 UTC (permalink / raw)
To: Allen Wang; +Cc: 60810
Allen Wang <allenhw1996@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
2023-01-15 1:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-15 7:08 ` Eli Zaretskii
2023-01-15 9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2023-01-15 7:08 UTC (permalink / raw)
To: Po Lu; +Cc: allenhw1996, 60810
> Cc: 60810@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@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
2023-01-15 7:08 ` Eli Zaretskii
@ 2023-01-15 9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-15 20:48 ` Allen Wang
0 siblings, 1 reply; 5+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-01-15 9:41 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: allenhw1996, 60810
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw
2023-01-15 9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-01-15 20:48 ` Allen Wang
0 siblings, 0 replies; 5+ messages in thread
From: Allen Wang @ 2023-01-15 20:48 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, 60810
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
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@yahoo.com> wrote:
> Eli Zaretskii <eliz@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.
>
[-- Attachment #2: Type: text/html, Size: 1245 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-01-15 20:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-14 8:07 bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw Allen Wang
2023-01-15 1:36 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-15 7:08 ` Eli Zaretskii
2023-01-15 9:41 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-15 20:48 ` Allen Wang
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).