Latency profiling?

Latency profiling?

[Sebastian Sturm]

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

Re: Latency profiling?

[Eli Zaretskii]

> From: Sebastian Sturm <s.sturm@arkona-technologies.de>
> Date: Sun, 18 Mar 2018 21:29:54 +0100
> 
> What is the best way to emulate interactive user input and reliably 
> assess the speed with which said input is processed?

If the slowdown is related to display, you can't do that except
interactively.

> 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)?

What's the difference?  There will be no latency if the time that
takes to process a command is short.

> 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.

If you suspect (or have evidence) that the time is spent in the C
code, I suggest to use perf.

Re: Latency profiling?

[Stefan Monnier]

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

I guess what you want is to use execute-kbd-macro in an interactive
Emacs session.  Tho, currently it seems that execute-kbd-macro will end
up short-circuiting the redisplay (normally redisplay is called when we
call keyboard.c:read_char, but while inside a keyboard-macro this
function will return the next "key" immediately without getting to the
redisplay call).

I think it would be valuable to make such an execution mode available
(you can probably mimick it tolerably well by just adding explicit
(redisplay t) calls between each command).


        Stefan

Re: Latency profiling?

[Joseph Garvin]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

You could use a bash script that selects the Emacs window with wmctrl,
attaches perf to the Emacs PID, then loops using xdotool to emulate
keyboard presses while the window is visible and has focus for some number
of iterations, then stops perf.

On Mar 18, 2018 8:25 PM, "Stefan Monnier" <monnier@iro.umontreal.ca> wrote:

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

I guess what you want is to use execute-kbd-macro in an interactive
Emacs session.  Tho, currently it seems that execute-kbd-macro will end
up short-circuiting the redisplay (normally redisplay is called when we
call keyboard.c:read_char, but while inside a keyboard-macro this
function will return the next "key" immediately without getting to the
redisplay call).

I think it would be valuable to make such an execution mode available
(you can probably mimick it tolerably well by just adding explicit
(redisplay t) calls between each command).


        Stefan

[-- Attachment #2: Type: text/html, Size: 1486 bytes --]

Re: Latency profiling?

[Sebastian Sturm]

thank you, this approach seems to work very well in combination with 
perf probe / record / script.
I'd appreciate some pointers on where to best insert user space probes 
to measure perceived input latency. I.e., which C functions are invoked 
by Emacs when it begins/finishes redisplay, and when it's ready to 
accept further user input?
Skimming over some of Emacs's source code, start_display, 
set_waiting_for_input, read_char and make_lispy_event caught my eye; am 
I on the right track here, or should I be looking at something else?

On 03/19/2018 03:01 AM, Joseph Garvin wrote:
> You could use a bash script that selects the Emacs window with wmctrl, 
> attaches perf to the Emacs PID, then loops using xdotool to emulate 
> keyboard presses while the window is visible and has focus for some 
> number of iterations, then stops perf.
> 
> On Mar 18, 2018 8:25 PM, "Stefan Monnier" <monnier@iro.umontreal.ca 
> <mailto:monnier@iro.umontreal.ca>> wrote:
> 
>      > What is the best way to emulate interactive user input and
>     reliably assess
>      > the speed with which said input is processed?
> 
>     I guess what you want is to use execute-kbd-macro in an interactive
>     Emacs session.  Tho, currently it seems that execute-kbd-macro will end
>     up short-circuiting the redisplay (normally redisplay is called when we
>     call keyboard.c:read_char, but while inside a keyboard-macro this
>     function will return the next "key" immediately without getting to the
>     redisplay call).
> 
>     I think it would be valuable to make such an execution mode available
>     (you can probably mimick it tolerably well by just adding explicit
>     (redisplay t) calls between each command).
> 
> 
>              Stefan
> 
> 
>