On Sun, Oct 13, 2019 at 11:45 AM Eli Zaretskii 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 Mojave. 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 all. João