[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Existing redisplay profiling tool?
From: |
Eli Zaretskii |
Subject: |
Re: Existing redisplay profiling tool? |
Date: |
Mon, 16 Sep 2024 15:19:57 +0300 |
> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 15 Sep 2024 23:16:48 -0700
> Cc: emacs-devel@gnu.org
>
> > How about using the scrolling benchmark through xdisp.c while
> > profiling?
> >
> > (defun scroll-up-benchmark ()
> > (interactive)
> > (let ((oldgc gcs-done)
> > (oldtime (float-time)))
> > (condition-case nil (while t (scroll-up) (redisplay))
> > (error (message "GCs: %d Elapsed time: %f seconds"
> > (- gcs-done oldgc) (- (float-time) oldtime))))))
> >
> > Evaluate the above, then turn on profiling, then type
> > "M-x scroll-up-benchmark RET" with point at beginning
> > of buffer that visits xdisp.c under c-ts-mode.
>
> Thanks! I’m hoping to measure the perceived responsiveness when typing text
> in the buffer, so here’s what I came up with:
>
> (let ((prev-time (current-time))
> (measurements nil))
> (dotimes (_ 100)
> (insert "s")
> (redisplay)
> (push (float-time (time-subtract (current-time) prev-time))
> measurements)
> (setq prev-time (current-time)))
> (message "Average time: %f"
> (/ (apply #'+ measurements) (length measurements))))
>
> Do you think this accurately measures the redisplay time between each
> keystroke? (Obviously this doesn’t take account of post-command-hook, I only
> want to measure repose & redisplay here.)
I don't understand why you measure only insertion of a single
character. This kind of change to buffer text is so frequent that it
has special optimizations in the display engine, and you might be
measuring only those special optimizations.
I proposed a scrolling benchmark because it executes the font-lock
code many times, and is more expensive than insertion of a single
character. You might as well try both, and could learn different
things from each other.
A variant of the above scrolling benchmark is scrolling by many lines
in one go (it causes a larger mismatch between the previous and the
current window, so redisplay is forced to use yet another code path
for that):
(defun scroll-up-by-40-benchmark ()
(interactive)
(let ((oldgc gcs-done)
(oldtime (float-time)))
(condition-case nil (while t (scroll-up 40) (redisplay))
(error (message "GCs: %d Elapsed time: %f seconds"
(- gcs-done oldgc) (- (float-time) oldtime))))))
> If that’s an accurate measurements, then my optimization doesn’t make any
> significant difference :-)
> In xdisp.c, inserting 100 “s” takes about 17.8ms per “keystroke” on average.
> With optimization it’s about 16.7ms, not much difference.
That's because redisplay is careful to redraw only a single screen
line when a single character is added. I'm not sure this is the only
situation that is interesting for you, but then I don't really know
what you are trying to optimize.
> I guess the takeaway is a) my new optimization doesn’t do anything, and b)
> tree-sitter font-lock doesn’t add human-perceivable latency when typing.
Try the other benchmarks, and maybe you will arrive at different
conclusions.