Re: Latency profiling?

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

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