|
From: | Dmitry Gutov |
Subject: | Re: How to measure frame rate in fps? |
Date: | Sun, 6 Jun 2021 19:48:17 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 |
On 06.06.2021 15:36, Eli Zaretskii wrote:
Then I don't see how this is relevant to the issue with the GTK tool bar making "do-nothing" redisplays more expensive. The above is a completely different scenario; depending on what exactly was Emacs doing in this scenario, redrawing of the GTK tool bar could indeed account for an insignificant percentage of the CPU time.
In my scenario the observable window configuration doesn't change between redisplays (though, of course, "current buffer" is switched multiple times under the covers, to send request and parse/receive response), and the values of point (again, during redisplay), are only 1 character position apart.
So if there is some caching of the toolbar contents, I don't see why it wouldn't work. I'm also not sure how rendering it can take 10-15 extra milliseconds, but for all I know this could be normal.
Since the code path that calls (redisplay) in Company is only triggered when talking to an external process (or, more generally, when the backend does something that allows a timer to run), to test this I repeatedly exercise completion using an external service, talking to it via HTTP/JSON.And what are you trying to investigate or establish with profiling this scenario? Maybe I simply don't understand what you wanted to demonstrate.
That toolbar being enabled has a somewhat unexpected effect on redisplay performance.
[Prev in Thread] | Current Thread | [Next in Thread] |