Re: How to measure frame rate in fps?

[Eli Zaretskii <eliz@gnu.org>]

> Cc: wyuenho@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 6 Jun 2021 15:00:50 +0300
> 
> > 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.

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.

> 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.

> >>      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.

Sure.