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

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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.