[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 19:28:25 +0100

On Tue, Oct 15, 2019 at 7:48 AM Eli Zaretskii <address@hidden> wrote:

> This is encouraging, but please try C-n near the end of xdisp.c, so
> that it includes syms_of_xdisp.  The first 350 lines of xdisp.c is one
> large comment, and there's a very small number of strings after that.

OK. So same setup as before but running on Windows 10 on a i7

30 seconds from syms_of_xdisp (void) in src/xdisp.c:
  with antiblink: 34969, around 7% load measured by Process Explorer
  without: 34977, also around 7% load
So I'd venture to say this didn't change much.

I think the reason the C-n and C-v tests escape a big performance hit is
that the potentially expensive operation, 'syntax-ppss', doesn't get
called when you you have switched lines.  So the presence or absence of
strings is irrelevant.  The most expensive operation will probably be
`line-beginning-position` which is in C and apparently fast enough to
not have any kind of relative impact.

But now that I notice, the beginning of jit-lock--antiblink-post-command
could be improved slightly to shortcut earlier and avoid one extra
`line-beginning-position' call in these cases (though probably these
rough benchmarks wouldn't show it.)

So to summarize, for the "paging" scenario, the overhead of the
post-command-based antiblink can be as low a 'copy-marker', an argless
'line-beginning-position' and few tests.

Assuming you're OK with the performace aspects of the thing, I'll do the
fixes you suggested earlier and re-submit (or push?)


reply via email to

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