Re: How to add pseudo vector types

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Cc: Clément Pit-Claudel <cpitclaudel@gmail.com>,
>>   emacs-devel@gnu.org
>> Date: Fri, 23 Jul 2021 19:57:32 -0700
>> 
>> > How much "less"?  Close to 1 sec is indeed annoying, but 20 msec or so
>> > should be bearable.
>> >
>> > You seem to assume up front that TS (re)-parsing will take 1 sec, but
>> > AFAIK there's no reason to assume such bad performance.
>> 
>> This is for the initial parse, on a large file. No matter how fast the
>> parser is, I can give you a file that takes one second to parse, and
>> some user will have such a file (the work always expands to consume all
>> the resources available).
>
> That problem is already with us: if I visit xdisp.c in an unoptimized
> build of Emacs 28, I wait almost 4 sec for the first window-full to be
> displayed.  (It's more like 0.5 sec in an optimized build of Emacs
> 27.2.)  So the real question is how much using TS will _improve_ the
> situation.

Yes. But here other solutions, like parsing only part of the buffer,
offer much better improvement.

>> I just got incremental parse working well enough to measure it; in the
>> largest Ada file I have (10,000 lines from Eurocontrol):
>> 
>> initial parse:       1.539319 seconds
>> re-indent two lines: 0.038999 seconds
>> 
>> 39 milliseconds for re-indent is just slow enough to be noticeable; I still
>> have algorithms to convert to be as incremental as possible.
>
> For comparison, how much does re-indentation of 2 lines take in Emacs
> without a parser?

I don't think this is a meaningful question, or at least, I don't have
an answer.

For ada-mode, you'd have to go back to version 4.0, where the
indentation was ad-hoc elisp. It was fast enough to be not noticeable.
But I switched to a parser because that indentation algorithm was often
incorrect, and was very brittle in the face of new features in new Ada
language standard releases.

Other languages don't use a parser for indentation, so there's no way to
compare. Even the AdaCore editor Gnat Studio doesn't use their parser
for indentation in Ada; Emacs ada-mode is the only one I know of.

I guess you could say it's a trade of indentation quality vs speed.
Witness the recent thread about inconsistent fontification in C; a
parser would resolve that, but LSP via eglot is probably slower than the
current elisp. Indentation is similar, but the quality difference is
bigger, at least for Ada.

> 39 msec might be noticeable, but it isn't annoying; anything below 50
> msec isn't.  

You are right; in that large Ada file, I don't notice the font-lock
delay after typing each character.

> Try "C-x TAB" in Emacs on 10-line block of text, and you get more than
> that.

Depends on the mode;

text-mode: 0.4 microseconds.

In xdisp.c, indenting it_char_has_category, 47.5 milliseconds.

In benchmark.el, indenting benchmark-call; 1.2 milliseconds.

The computation here is font-lock due to the text moving in the buffer;
in the ada-mode benchmark above, it is computing indent. Calling
indent-rigidly, then indent-region (which results in zero net buffer
change, so apparently no significant font-lock), I get:

xdisp.c: 17.1 ms

benchmark.el: 3.6 ms

-- 
-- Stephe