Hi everyone, I've gotten into a discussion with isort's author about how fast editors can actually render text. I was just wondering if there are any built-in facilities that can measure framerate in FPS in emacs? Thanks, Jimmy Yuen Ho Wong
Jimmy Yuen Ho Wong <wyuenho@gmail.com> writes:
> Hi everyone,
>
> I've gotten into a discussion with isort's author about how fast
> editors can actually render text.
FPS is not necessary the measure of how fast you can render text. Sure
it directly affects fps, but fps is more complex than just how fast text
is rendered. It is also affected by how fast your hardware and OS can
swap frames, how your OS multitasks processes etc. When you read
benchmarks at sites like Tomshardware, notice that they use different
games and applications to measure the performance. They really are
concerned with how the underlaying hardware and OS perform in that
particular game and application. Different games will result with
different number of FPS. So FPS is just a relative measure for the
application at hand.
How fast text can be rendered on any computer depends on the hardware of
course and how efficiently code used to render text use that
hardware. Most "normal" applications like text processors will use
whatever the OS provides. I guess you have to ask Mr. Eliz & Co for the
details about how Emacs renders text, or look at the source.
Anyway, you could create small app to some teoretical speed of how much
text you could render on your own computer with your choice of the
library. "Theoretical" because it is really difficult to get
reliable measure when it comes to just rendering speed on modern
computers since cpus run at variable speed to save the energy, OSs are
scheduling processes and stuff at they will, data has to be send over
the bus to gpu if there is one, and so on.
For the Emacs I don't think you can get a meaningful measure "out of the
box" since Emacs run in a blocking event qeue, which means Emacs does
nothing unless there is input. Maybe you could construct a test and
render a considerably big piece of text in an empty buffer and take the
time, repeat several times and take mean time, to give you some feel of
howa fast it happends, but I am not sure how reliably you could do this
in Emacs.
I don't think it matters much either. Most CPUs can render "enough" text,
fast enough that it really isn't important. What does it matter if one
can render 10 billion characters at 144 fps, if one can display only few
hundreds or max few thousands at the time on the screen? Who
cares. Consider a Ferrari vs a Volvo. Sure, Ferrari is faster, but Volvo
will do the jobb 99% of the time for 99% of the people.
> From: Jimmy Yuen Ho Wong <wyuenho@gmail.com>
> Date: Mon, 31 May 2021 14:03:17 +0100
>
> I've gotten into a discussion with isort's author about how fast
> editors can actually render text. I was just wondering if there are
> any built-in facilities that can measure framerate in FPS in emacs?
Emacs doesn't work at a fixed "frame rate". It attempts to optimize
each update of the screen as much as possible, so the actual time to
perform a single update of a window depends on how much stuff on the
screen needs to be changed since the previous redisplay cycle. As
result, you will find that the redisplay time could vary by a factor
of 10 if not more, depending on what changed in the editor's internal
state. Moreover, the first phase of redisplay, the one that
determines what needs to be redrawn, might decide to redraw something,
but the second phase, which actually writes to the glass, can decide
that nothing needs to be redrawn. I don't know how to quantify the
speed of "redrawing" when nothing is actually redrawn, although some
CPU cycles are expended.
That said, you can measure the time it takes to redisplay after some
change using the "M-x benchmark" command to time the function
'redisplay'. You just need to remember to include some command that
would affect the display, or else redisplay will do very little and
redraw nothing. For example:
C-u 100 M-x benchmark RET (progn (scroll-up) (redisplay)) RET
or
C-u 100 M-x benchmark RET (progn (insert "a") (redisplay)) RET
(The former is better tried in a buffer that has more than 100
screenfuls of text.)
Then subtract the time it takes to run the same benchmark, but without
the "(redisplay)" part, divide the result by 100, and you get the time
it takes to redisplay a single window.
On 01.06.2021 14:43, Eli Zaretskii wrote:
> You just need to remember to include some command that
> would affect the display, or else redisplay will do very little and
> redraw nothing.
Speaking of redisplay redrawing nothing, as long as tool-bar-mode is on,
my GTK3 build (with -Q even) evaluates (benchmark 1 '(redisplay)) to a
sequence of results like this:
Elapsed time: 0.040924s
Elapsed time: 0.026343s
Elapsed time: 0.023473s
Elapsed time: 0.025162s
Elapsed time: 0.030074s
Elapsed time: 0.041305s (0.026917s in 1 GCs)
Elapsed time: 0.031169s
Elapsed time: 0.020957s
Elapsed time: 0.034885s
Elapsed time: 0.035338s
Elapsed time: 0.030864s
and with tool-bar-mode off:
Elapsed time: 0.007189s
Elapsed time: 0.006181s
Elapsed time: 0.007358s
Elapsed time: 0.004177s
Elapsed time: 0.007754s
Elapsed time: 0.007557s
Not so noticeable if it just happens once, but easily affects the
performance of code which performs "virtual" redisplay, such as
posn-at-point.
Sometimes the effect disappears (even with tool-bar-mode on), but to
bring it back I only had to call (redisplay t) once.
> Cc: emacs-devel@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Tue, 1 Jun 2021 17:18:09 +0300 > > On 01.06.2021 14:43, Eli Zaretskii wrote: > > You just need to remember to include some command that > > would affect the display, or else redisplay will do very little and > > redraw nothing. > > Speaking of redisplay redrawing nothing, as long as tool-bar-mode is on, > my GTK3 build (with -Q even) evaluates (benchmark 1 '(redisplay)) to a > sequence of results like this: > > Elapsed time: 0.040924s > Elapsed time: 0.026343s > Elapsed time: 0.023473s > Elapsed time: 0.025162s > Elapsed time: 0.030074s > Elapsed time: 0.041305s (0.026917s in 1 GCs) > Elapsed time: 0.031169s > Elapsed time: 0.020957s > Elapsed time: 0.034885s > Elapsed time: 0.035338s > Elapsed time: 0.030864s > > and with tool-bar-mode off: > > Elapsed time: 0.007189s > Elapsed time: 0.006181s > Elapsed time: 0.007358s > Elapsed time: 0.004177s > Elapsed time: 0.007754s > Elapsed time: 0.007557s I know very little about the cost of the GTK tool bar redrawing: the code is in gtkutil.c, and it's full of GTK API calls. Maybe the above times are explained and justified by that, I don't know. I also am not sure the above faithfully reflects what happens in Real Life when Emacs has nothing to redisplay: I think you get the tool-bar redisplay triggered because the evaluation of the benchmark call causes it somehow. How did you evaluate it, exactly? > Not so noticeable if it just happens once, but easily affects the > performance of code which performs "virtual" redisplay, such as > posn-at-point. How do you deduce that posn-at-point triggers redisplay of the GTK tool bar? It shouldn't, AFAIR. posn-at-point and its ilk only simulate display of text, they don't care about window's and frame's decorations.
On 01.06.2021 17:43, Eli Zaretskii wrote: > I know very little about the cost of the GTK tool bar redrawing: the > code is in gtkutil.c, and it's full of GTK API calls. Maybe the above > times are explained and justified by that, I don't know. Sometimes the times are high like this, sometimes they are lower. Could be it's another GTK bug, and there's nothing we can do, but it's probably a bug *somewhere*. > I also am not sure the above faithfully reflects what happens in Real > Life when Emacs has nothing to redisplay: I think you get the tool-bar > redisplay triggered because the evaluation of the benchmark call > causes it somehow. How did you evaluate it, exactly? Either using M-:, or with M-x benchmark like you suggested (only without prefix argument, to measure just 1 iteration). The results are similar. >> Not so noticeable if it just happens once, but easily affects the >> performance of code which performs "virtual" redisplay, such as >> posn-at-point. > > How do you deduce that posn-at-point triggers redisplay of the GTK > tool bar? It shouldn't, AFAIR. posn-at-point and its ilk only > simulate display of text, they don't care about window's and frame's > decorations. You're right, posn-at-point shows me different timings. Often enough as high as 12-15ms, which is not great for a low latency display, but the numbers don't seem to be tied to tool-bar-mode being on. But we end up calling `redisplay` explicitly on a different code path in Company (when a backend talks to an external process, basically), so it's still affected by how long that takes.
> Cc: wyuenho@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Tue, 1 Jun 2021 18:00:35 +0300 > > > I also am not sure the above faithfully reflects what happens in Real > > Life when Emacs has nothing to redisplay: I think you get the tool-bar > > redisplay triggered because the evaluation of the benchmark call > > causes it somehow. How did you evaluate it, exactly? > > Either using M-:, or with M-x benchmark like you suggested (only without > prefix argument, to measure just 1 iteration). The results are similar. Yes, that figures: entering the minibuffer triggers a more thorough redisplay than usual: we redisplay the menu bar, the tool bar, and several other things as result, for reasons that should be obvious. Try C-x C-e instead after typing the sexp in *scratch. In that scenario, I don't expect the tool bar to be redrawn. > > How do you deduce that posn-at-point triggers redisplay of the GTK > > tool bar? It shouldn't, AFAIR. posn-at-point and its ilk only > > simulate display of text, they don't care about window's and frame's > > decorations. > > You're right, posn-at-point shows me different timings. Often enough as > high as 12-15ms, which is not great for a low latency display, but the > numbers don't seem to be tied to tool-bar-mode being on. If you want me to take a look at those 15ms cases, I suggest to file a bug report with the details and a recipe.
On 01.06.2021 18:35, Eli Zaretskii wrote: > Yes, that figures: entering the minibuffer triggers a more thorough > redisplay than usual: we redisplay the menu bar, the tool bar, and > several other things as result, for reasons that should be obvious. > > Try C-x C-e instead after typing the sexp in *scratch. In that > scenario, I don't expect the tool bar to be redrawn. Thanks, that's a better methodology. I still see long-ish redisplays in my "real world" scenario, with timings like Elapsed time: 0.003500s Elapsed time: 0.026936s Elapsed time: 0.024454s Elapsed time: 0.024453s on redisplay with tool-bar-mode on and Elapsed time: 0.005239s Elapsed time: 0.005562s Elapsed time: 0.014864s Elapsed time: 0.014525s Elapsed time: 0.005216s Elapsed time: 0.014419s Elapsed time: 0.015004s Elapsed time: 0.010501s Elapsed time: 0.013163s with it off (both measured with 'benchmark-progn' injected in some working code), but none of that with 'emacs -Q'. Perhaps those are to be expected (even though the Emacs frame doesn't change much, the scenario involves 1 or 2 network calls). >>> How do you deduce that posn-at-point triggers redisplay of the GTK >>> tool bar? It shouldn't, AFAIR. posn-at-point and its ilk only >>> simulate display of text, they don't care about window's and frame's >>> decorations. >> >> You're right, posn-at-point shows me different timings. Often enough as >> high as 12-15ms, which is not great for a low latency display, but the >> numbers don't seem to be tied to tool-bar-mode being on. > > If you want me to take a look at those 15ms cases, I suggest to file a > bug report with the details and a recipe. With updated testing approach, I don't see those timings with posn-at-point anymore, thanks. The only repro I still see is the one described above, in the "complex" scenario. Not sure if it's worth reporting, or if the numbers simply look correct.
> Cc: wyuenho@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 2 Jun 2021 00:31:37 +0300
>
> With updated testing approach, I don't see those timings with
> posn-at-point anymore, thanks.
>
> The only repro I still see is the one described above, in the "complex"
> scenario. Not sure if it's worth reporting, or if the numbers simply
> look correct.
Maybe run Emacs under 'perf' and see which GTK API call(s) take(s)
most of those milliseconds?
On 02.06.2021 05:29, Eli Zaretskii wrote:
> Maybe run Emacs under 'perf' and see which GTK API call(s) take(s)
> most of those milliseconds?
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
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
1,82% emacs emacs [.]
pdumper_marked_p_impl
1,80% emacs emacs [.]
re_match_2_internal
1,69% emacs emacs [.]
lookup_char_property
1,57% emacs emacs [.]
set_buffer_internal_2
1,54% emacs emacs [.] eval_sub
1,42% emacs emacs [.] Fassq
1,41% emacs emacs [.] sweep_conses
1,33% emacs emacs [.] sweep_vectors
1,02% emacs emacs [.] exec_byte_code
0,97% emacs emacs [.] mark_vectorlike
0,95% emacs emacs [.] next_interval
0,92% emacs emacs [.] find_interval
0,79% emacs libc-2.31.so [.]
__memmove_avx_unaligned_erms
0,64% emacs emacs [.]
pdumper_set_marked_impl
0,62% emacs libc-2.31.so [.] malloc
0,62% emacs emacs [.] Fcons
0,61% emacs libc-2.31.so [.] _int_malloc
0,58% emacs emacs [.]
gui_produce_glyphs
0,52% emacs emacs [.] list_length
0,49% emacs emacs [.] Ffuncall
0,46% emacs emacs [.] Fcdr
0,42% emacs libpthread-2.31.so [.]
__pthread_mutex_unlock
0,40% emacs emacs [.]
scan_sexps_forward
0,40% emacs libpthread-2.31.so [.]
__pthread_mutex_lock
0,38% emacs emacs [.]
allocate_vectorlike
0,36% emacs libcairo.so.2.11600.0 [.]
cairo_scaled_font_text_to_glyphs
0,36% emacs emacs [.]
composition_compute_stop_pos
0,35% emacs emacs [.]
bidi_resolve_explicit
0,35% emacs emacs [.]
get_next_display_element
0,35% emacs emacs [.] Fplist_get
0,34% emacs libc-2.31.so [.] _int_free
0,33% emacs emacs [.] Faref
0,33% emacs emacs [.]
move_it_in_display_line_to
0,32% emacs emacs [.]
balance_an_interval
0,32% emacs emacs [.] get_keymap
0,29% emacs emacs [.]
do_symval_forwarding
0,28% emacs emacs [.]
set_default_internal
0,26% emacs emacs [.] hash_lookup
0,26% emacs emacs [.]
vectorlike_nbytes
0,25% emacs emacs [.]
rpl_re_compile_pattern
0,25% emacs emacs [.] json_to_lisp
0,25% emacs emacs [.]
bidi_level_of_next_char
0,24% emacs libc-2.31.so [.]
malloc_consolidate
0,23% emacs emacs [.]
bidi_resolve_weak
0,23% emacs emacs [.]
find_automatic_composition
0,23% emacs emacs [.] grow_specpdl
0,23% emacs emacs [.] mark_compiled
> Cc: wyuenho@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 6 Jun 2021 05:09:09 +0300 > > On 02.06.2021 05:29, Eli Zaretskii wrote: > > Maybe run Emacs under 'perf' and see which GTK API call(s) take(s) > > most of those milliseconds? > > 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. > 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? > 0,25% emacs emacs [.] json_to_lisp Any idea why this is here? (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.)
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.
> 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.
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.
> Cc: wyuenho@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 6 Jun 2021 19:48:17 +0300 > > 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. First, that nothing changes on the glass doesn't mean redisplay isn't working, because it isn't (always) omniscient. More importantly, I no longer understand what are we discussing. AFAIU, you have some scenario where Emacs is performing some non-trivial processing, and where in your opinion redisplay should not have changed anything on display. Is that correct? If so, please take me from this point and explain what is the issue you see. > 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. The 10-15 milliseconds was measured in a different situation, AFAIU: an idle "emacs -Q". Is that correct? > > 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. I don't think I understand how you conclude this. I see no traces of redisplay functions in the profile you have shown.
> 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.
Maybe we could get a better picture of what's going on by comparing
profiles with and without toolbar.
But I suspect that the various between profiles is large enough without
any configuration changes that we'd need to compare like 10 profiles
with toolbar against 10 profiles without toolbar before we can start to
(maybe) see a pattern emerge.
Stefan
On 06.06.2021 20:19, Eli Zaretskii wrote: >> Cc: wyuenho@gmail.com, emacs-devel@gnu.org >> From: Dmitry Gutov <dgutov@yandex.ru> >> Date: Sun, 6 Jun 2021 19:48:17 +0300 >> >> 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. > > First, that nothing changes on the glass doesn't mean redisplay isn't > working, because it isn't (always) omniscient. Of course. > More importantly, I no longer understand what are we discussing. > AFAIU, you have some scenario where Emacs is performing some > non-trivial processing, and where in your opinion redisplay should not > have changed anything on display. Is that correct? If so, please > take me from this point and explain what is the issue you see. I have one scenario, which I run with toolbar disabled, then enabled, then disabled, then enabled again. With a (benchmark-progn ...) wrapped around a (redisplay) call, to note how long it really takes in practice. I'm saying that the buffer, or other window configuration, don't change at those points, so the toolbar likely doesn't need to be re-rendered, and so the extra overhead is surprising. And that the toolbar taking 10-15ms to re-render isn't great either in any case. >> 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. > > The 10-15 milliseconds was measured in a different situation, AFAIU: > an idle "emacs -Q". Is that correct? It's the difference, computed very roughly. Let me show you the contents of the Messages buffer. The times printed are reported by the (benchmark-progn (redisplay)) form: Elapsed time: 0.000250s Elapsed time: 0.020975s Elapsed time: 0.021575s Elapsed time: 0.018466s Elapsed time: 0.019960s Elapsed time: 0.019763s Elapsed time: 0.018882s Elapsed time: 0.017270s Elapsed time: 0.021255s Elapsed time: 0.008013s Elapsed time: 0.027652s Elapsed time: 0.025234s Elapsed time: 0.016007s Elapsed time: 0.020156s Elapsed time: 0.019670s Elapsed time: 0.016077s Elapsed time: 0.009564s Elapsed time: 0.007729s Elapsed time: 0.010654s Elapsed time: 0.015931s Elapsed time: 0.005864s Tool-Bar mode enabled Elapsed time: 0.002618s Elapsed time: 0.029224s Elapsed time: 0.012488s Elapsed time: 0.035648s Elapsed time: 0.034038s Elapsed time: 0.029158s Elapsed time: 0.032658s Elapsed time: 0.031887s Elapsed time: 0.034134s Elapsed time: 0.032638s Elapsed time: 0.033091s Elapsed time: 0.033695s Elapsed time: 0.032838s Elapsed time: 0.023070s Elapsed time: 0.033654s Elapsed time: 0.016566s Elapsed time: 0.028871s Elapsed time: 0.012279s Elapsed time: 0.026500s Elapsed time: 0.027658s Elapsed time: 0.032699s Elapsed time: 0.013483s Elapsed time: 0.030350s Elapsed time: 0.030031s Elapsed time: 0.045297s Elapsed time: 0.025866s Elapsed time: 0.032220s Elapsed time: 0.012934s Elapsed time: 0.032216s Elapsed time: 0.031713s Elapsed time: 0.030811s Elapsed time: 0.013024s Elapsed time: 0.032237s Elapsed time: 0.012812s Elapsed time: 0.021457s Elapsed time: 0.025366s Elapsed time: 0.032519s Elapsed time: 0.025441s Elapsed time: 0.031464s Elapsed time: 0.012804s Elapsed time: 0.012951s Elapsed time: 0.034065s Elapsed time: 0.032018s Elapsed time: 0.033917s Elapsed time: 0.030410s Elapsed time: 0.012490s Elapsed time: 0.034950s Elapsed time: 0.032683s Elapsed time: 0.012379s Elapsed time: 0.017438s Elapsed time: 0.036289s Mark set Quit Tool-Bar mode disabled Elapsed time: 0.000336s Elapsed time: 0.004768s Elapsed time: 0.018090s Elapsed time: 0.016751s Elapsed time: 0.015772s Elapsed time: 0.006628s Elapsed time: 0.017676s Elapsed time: 0.015837s Elapsed time: 0.021333s Elapsed time: 0.019190s Elapsed time: 0.018478s Elapsed time: 0.018915s Elapsed time: 0.014479s Elapsed time: 0.005889s Elapsed time: 0.022493s Elapsed time: 0.011403s Elapsed time: 0.011022s Elapsed time: 0.020275s Elapsed time: 0.006469s Elapsed time: 0.019499s Elapsed time: 0.005800s Elapsed time: 0.004827s Elapsed time: 0.008394s Elapsed time: 0.029546s Elapsed time: 0.007446s Elapsed time: 0.008475s Elapsed time: 0.008290s Elapsed time: 0.000402s Elapsed time: 0.004851s Elapsed time: 0.019022s Elapsed time: 0.020623s Elapsed time: 0.005188s Elapsed time: 0.021102s Elapsed time: 0.019203s Elapsed time: 0.005724s Elapsed time: 0.019243s Elapsed time: 0.018614s Elapsed time: 0.021920s Elapsed time: 0.019716s Tool-Bar mode enabled Elapsed time: 0.002532s Elapsed time: 0.013393s Elapsed time: 0.011731s Elapsed time: 0.033731s Elapsed time: 0.012756s Elapsed time: 0.030029s Elapsed time: 0.011511s Elapsed time: 0.033465s Elapsed time: 0.022545s Elapsed time: 0.023758s Elapsed time: 0.019158s Elapsed time: 0.015410s Elapsed time: 0.039764s Elapsed time: 0.034458s Elapsed time: 0.033955s Elapsed time: 0.029793s Elapsed time: 0.016531s Elapsed time: 0.034445s Elapsed time: 0.024124s Elapsed time: 0.029344s Elapsed time: 0.016216s Elapsed time: 0.031835s Elapsed time: 0.018600s Elapsed time: 0.026698s Elapsed time: 0.013067s Elapsed time: 0.029260s Elapsed time: 0.029213s Elapsed time: 0.013516s Elapsed time: 0.032331s Quit [2 times]
On 06.06.2021 21:10, Stefan Monnier wrote: >> 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. > > Maybe we could get a better picture of what's going on by comparing > profiles with and without toolbar. That's what I have been comparing. I can try and produce the corresponding pref recordings. Will that really help? Do I post them raw? > But I suspect that the various between profiles is large enough without > any configuration changes that we'd need to compare like 10 profiles > with toolbar against 10 profiles without toolbar before we can start to > (maybe) see a pattern emerge. My current reproduction scenario itself is fairly heavy, so it's no surprise if the functions are not at the top of the list.
> Cc: wyuenho@gmail.com, emacs-devel@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Mon, 7 Jun 2021 02:31:50 +0300 > > I have one scenario, which I run with toolbar disabled, then enabled, > then disabled, then enabled again. With a (benchmark-progn ...) wrapped > around a (redisplay) call, to note how long it really takes in practice. > > I'm saying that the buffer, or other window configuration, don't change > at those points, so the toolbar likely doesn't need to be re-rendered, > and so the extra overhead is surprising. And that the toolbar taking > 10-15ms to re-render isn't great either in any case. But in the profile you showed we didn't see any evidence of significant CPU usage by functions that redraw the GTK toolbar. So I'm not sure the overhead is due to redrawing the toolbar, although it might be _triggered_ by the presence of the toolbar. > It's the difference, computed very roughly. Let me show you the contents > of the Messages buffer. The times printed are reported by the > (benchmark-progn (redisplay)) form: How do you reconcile this with the 00.00% that GTK functions took? Can you see what does 'perf' say about functions from gtkutil.c that are related to toolbar redisplay?