[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: jit-lock-antiblink-grace

From: João Távora
Subject: Re: jit-lock-antiblink-grace
Date: Tue, 15 Oct 2019 00:29:51 +0100

On Sun, Oct 13, 2019 at 11:45 AM Eli Zaretskii <address@hidden> wrote:
> > ? Or should I add a `redisplay` or something else there?
> For timing the effect of post-command-hook, you need to actually
> invoke many commands.  I suggest to lean on the DOWN arrow for a fixed
> amount of time, say, 30 sec, and see how far into the file did you go,
> and what was the average CPU load (e.g, as shown by display-time-mode
> or by 'top').

OK, I found some time to run these "manual" tests:

So I tried this with and without the hook. I removed it (forcibly) with

 (remove-hook 'post-command-hook
               'jit-lock--antiblink-post-command t)
and re-added it with

 (add-hook 'post-command-hook
           'jit-lock--antiblink-post-command nil t)

before beginning the test.

I confirmed that without the hook the feature is crippled and fails, and
with the hook it works fine.  This was easier then launching separate
emacsen with jit-lock-antiblink-grace customized differently.

60 second-long C-n in src/xdisp.c,
  without antiblink: line 706, avg load 4%
  with antiblink: line 717, avg load 4%
30 second-long C-n in lisp/minibuffer.el,
  with antiblink: line 366, avg load 4%
  without antiblink: line 361, avg load 4%

Time to end of buffer with C-v in lisp/minibuffer.el:
  with antiblink: 10 seconds, avg load 6%
  without antiblink: 10 seconds, avg load 6%

Time to end of buffer with C-v in src/xdisp.c:
  without antiblink: 90 seconds, avg load 8%
  with antiblink: 91 seconds, avg load 8%

I ran this with Emacs -Q with git commit
079461b360a2467ff4ab2ec57516c6f9e45f50fe on a 2013 Macbook Air running

The CPU load averages are computed "in my mind" from looking at top(1)
output. Times are taken from a wristwatch.  Thus, not really precise
measurements at all.  So, because these tests are kind of boring to
conduct, I'd like you or someone else to reproduce (or fail to
reproduce) one or two results before going any further.

Nevertheless, I'd risk saying that your worries about the performance
impact on these particular "paging" operations may not materialize at


reply via email to

[Prev in Thread] Current Thread [Next in Thread]