Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Cc: eg642616@gmail.com,  77224@debbugs.gnu.org,  juri@linkov.net
>> Date: Thu, 27 Mar 2025 21:17:25 +0100
>>
>> Here we discuss changing only the color of the cursor, a much much less
>> complex operation.
>
> My point is that when the list on post-command-hook is long, it takes
> Emacs time to process all the functions on the list, and the longer
> the list, the less responsive Emacs will be.  These small
> insignificant delays add up.

I see your point. But not only the length of the list but also the
weight of the specific hook functions matters. A handful of
insignificant delays add up, but will still stay insignificant. There
are not that many hooks installed in the PCH list (see my list below).
In the reports where users complain about slow Emacs, it seems more
likely that one bad hook outweighs all the others.

> How long is the post-command-hook list in your production sessions?
> Should we poll users to give their data?  Just yesterday someone
> complained on Reddit that Emacs is too slow, and I have no doubt that
> features that use post-command-hook are at least part of the reason if
> not _the_ reason.

Indeed. PCHs are a common reason for slow down. Even worse are functions
which run during redisplay. Heavy custom mode lines seem to be the main
problem here.

My `post-command-hook' list looks like this:

Buffer-local:
(jit-lock--antiblink-post-command eldoc-schedule-timer
 corfu--auto-post-command jinx--reschedule
 whitespace-post-command-hook hl-line-highlight t)

Global:
(ibuffer-auto-update-changed repeat-post-hook)

I don't have any problems with these hooks, since they are either cheap
or only schedule some timers for more expensive operations. At least I
don't notice any sluggishness and the PCHs don't appear in profiles.