|Date:||Sun, 18 Mar 2018 21:29:54 +0100|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0|
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
|[Prev in Thread]||Current Thread||[Next in Thread]|