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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Mon, Aug 08, 2022 at 05:36:08 +0300, Eli Zaretskii wrote:
> > Date: Sun, 7 Aug 2022 19:20:44 +0000
> > Cc: gregory@heytings.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > > Either in the cache or in the buffer: the previous chunk was
> > > > > fontified, so its end has the font-lock-comment-face.  So you know.

> > > > No, you don't.  The buffer might be being opened by desktop in a large
> > > > comment in the middle of the file.

> > > 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.

> > > > What jit-lock/font-lock actually do at the moment is to widen, then use
> > > > syntax-ppss, i.e. in effect scan from BOB.

> > > Yes, and that's SLOOOWWWW!

> > 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.
Some things take a certain amount of time, and there's nothing we can do
about it.  (Of course we can do things about some other aspects.)

> > > > That "needing to go too far" is an instantaneous jump, not a scanning.

> > > Please tell that to someone who doesn't edit C sources as frequently
> > > as I do.

> > Are you saying that long strings and long comments cause a particular
> > slowdown in C Mode, not seen when strings and comments are all short?

> 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?

> > > > The string start will be in a parse-partial-sexp result somewhere.
> > > > Sometimes people write long strings.  They certainly write long comments.

> > > Why do I have top suffer every day just because someone, somewhere,
> > > might do that?  I'd rather we "punish" those few people who do it
> > > (rarely).

> > I don't think we should punish people who write comments.  I'm thinking
> > of Gerd M., who was likely the writer of the comment at the beginning of
> > xdisp.c.

> 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.

-- 
Alan Mackenzie (Nuremberg, Germany).