Re: Major modes using `widen' is a good, even essential, programming practice.

[Eli Zaretskii]

> Date: Mon, 8 Aug 2022 09:58:29 +0000
> Cc: gregory@heytings.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > You've changed the scenario, yes?
> 
> > > Yes.  We've got to deal with all scenarios, preferably without
> > > special-caseing special cases.
> 
> > No one said that all the scenarios must have the same solution.
> 
> I suppose not, but optimising for different scenarios would be, well, an
> optimisation.  Do we really need it.

I thought the facts and findings in this and related discussions
recently have shown beyond any reasonable doubt that we do.

> > > On my machine, with an optimised build, it takes just under 20 ms to
> > > parse-partial-sexp over xdisp.c (not counting any redisplay at the end).
> > > I don't understand any more than Dmitry does, why your unoptimised build
> > > is taking 25 times as long.
> 
> > It doesn't help to know that some very fast machine can do this stuff
> > quickly enough to remain below the annoyance threshold.  20 ms is a
> > very long time by the current CPU speed measure: just calculate the
> > number of CPU cycles in that time and you will see it.
> 
> We're talking about 1.2 MB here.  That works out at less than 17 ns per
> character.  Each round of the loop is a fairly sophisticated finite state
> machine pass.  Possibly it could be optimised, but I doubt by very much.

I guess you have just explained to yourself why processing all of the
buffer is unscalable?  Which was my point all the way.

> Some things take a certain amount of time, and there's nothing we can do
> about it.

Of course, there's something to do: do less of that!  This is exactly
the main idea behind narrowing, and any other similar limitations.

For example, bidi.c stops looking back for a paragraph's beginning if
it didn't find one within a predefined number of lines.  Failure to
find and process the paragraph's beginning could potentially produce
an utterly incorrect display of bidirectional text, but we do that
anyway.  Why? because it's unreasonable to slow down redisplay to a
crawl for the benefit of very rare situations.

Why cannot CC Mode do something similar, with a similar justification?

> > I don't know what makes it slow, but it feels sluggish in even the
> > simplest editing operations, and font-lock updates are slow as well.
> 
> How about us opening a bug report for CC Mode's speed with
> font-lock-maximum-decoration = 2?

Consider it open.  I'm sure I complained about this more than once
already, and yet here we are.

> > We are still talking about long lines, yes?  There are no long lines
> > in that commentary at the beginning of xdisp.c.
> 
> I don't think we were still talking about long lines.  We were talking
> about parse-partial-sexp on large files.

Well, I _am_ talking about long lines.  Because you insist on the
necessity to go far back even in that case.

When we solve the long-line case, we can consider the large-buffer
case, and perhaps even find that the same solution fits both.