Re: How to measure frame rate in fps?

[Dmitry Gutov <dgutov@yandex.ru>]

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.