[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latency profiling?

From: Sebastian Sturm
Subject: Re: Latency profiling?
Date: Sat, 24 Mar 2018 18:23:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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" <address@hidden <mailto:address@hidden>> 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).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]