Latency profiling?

[Sebastian Sturm <s.sturm@arkona-technologies.de>]

Hi,

when trying to pinpoint latency issues with my Emacs setup, my usual 
modus operandi is to start the profiler, wildly pound on the keyboard 
and look for suspicious hotspots in the resulting profile. This is 
usually good enough to resolve the most annoying performance issues, but 
the process is not as systematic as I'd like it to be and it is 
difficult to quantitatively evaluate code improvements or check for 
performance regressions across package updates.

I tried to profile elisp functions that involve a large number of 
editing or motion commands, but it seems to me that Emacs is smart 
enough to detect it's being used noninteractively (is that true?) and 
omits calls to many expensive eye candy functions (such as the 
lsp-ui/cquery sideline that displays type information on the C++ symbol 
at point).

What is the best way to emulate interactive user input and reliably 
assess the speed with which said input is processed?

Also, is there a way to profile not throughput, but latency (i.e. time 
elapsed between key press and Emacs being ready for further input)? As 
far as I can see, there are hooks invoked on self-insert-command, but I 
didn't find a hook that fires when redisplay is done. Anything that uses 
external tracing frameworks would also be fine in my book, as long as it 
runs on Linux.

best,
Sebastian Sturm