Re: How to measure frame rate in fps?

[Dmitry Gutov <dgutov@yandex.ru>]

On 06.06.2021 09:11, Eli Zaretskii wrote:

>> I'm not sure if I've been doing it right, but the gtk functions seem to
>> be taking pretty much none of the runtime:
>>
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_widget_get_direction
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_widget_get_type
>>
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_style_context_get_property
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_get_event_widget
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_style_context_get_type
>>      0,00%  emacs  libgtk-3.so.0.2404.16  [.] gtk_toolbar_get_type
> 
> Yes, looks like that.  Strange, since you did say disabling the tool
> bar makes a prominent difference.

A noticeable difference in the speed of (redisplay), as measured by 
benchmark-progn, in the middle of a more complex process.

>> The leaders looked like:
>>
>>     28,52%  emacs         emacs                       [.] mark_object
>>
>>      6,87%  emacs         emacs                       [.] assq_no_quit
>>
>>      3,45%  emacs         emacs                       [.] mark_char_table
>>
>>      3,37%  emacs         emacs                       [.] sweep_strings
>>
>>      2,84%  emacs         emacs                       [.] boyer_moore
> 
> Three out of 5 of the above mean Emacs spends a large proportion of
> the time (35%) doing GC.  I'm not sure I understand why should Emacs
> perform GC while being idle: do you have some timers running, perhaps?
> If this is "emacs -Q", what happens if you disable blink-cursor-mode
> and global-eldoc-mode?

No, I'm not measuring while idle. Like I said, those redisplays are in 
the middle of the "complex" scenario mentioned previously.

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.

>>      0,25%  emacs         emacs                       [.] json_to_lisp
> 
> Any idea why this is here?

...so both JSON decoding and GC being among the hot spots are totally 
expected.

> (I think "perf report" supports output in the form of a call-tree,
> where functions are shown with their callers?  That allows to better
> understand what high-level processing is running in Emacs than just
> looking at the profile sorted by percents.)

Let me know if you still need some of the calls expanded this way.