bug#45248: 28.0.50; Emacs freezes with big C functions

[Alan Mackenzie]

Hello, Ravine.

Thanks again for the fast testing and reply.

On Fri, Dec 18, 2020 at 16:47:36 +0530, Ravine Var wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > As Eli surmised, the problem is the very large static struct in the
> > function.

> > The solution appears to be to cache positions within structs, so that
> > the function searching back over brace lists needn't do so repeatedly in
> > the same piece of buffer.

> > I'm hoping that the following patch which implements this cache will
> > solve the problem.  Would you please apply it to your copy of the master
> > branch, byte compile it, and try it out on various CC Mode buffers.
> > Then please let me know how well it has fixed the bug.  Thanks!

> The patch didn't apply cleanly on master, but it still went through.

Sorry, I should have asked you to do $ cd lisp/progmodes first.  But I'm
glad you got it applied anyway.

> progmodes $ patch -p1 < ~/Downloads/patches/bug_45248_message_11.mbox

[ .... ]

> Testing with the large structure copied into a file showed
> some initial improvement, but the screen still locked up
> once scrolling reached 15% or so.

> Enabling fast-but-imprecise-scrolling allowed scrolling
> to happen, but there was lots of stuttering.

> Profile report with emacs -Q on a Ryzen-based machine
> (no fast-but-imprecise-scrolling):

> https://gist.github.com/ravine-var/0116c20477dce725b02543a85e91cbab

Thanks for the profile.  Noticeable in it is that
c-looking-at-or-maybe-in-bracelist isn't taking up masses of runtime any
more.  The profile is virtually identical to one I generated myself (on
my own Ryzen machine).

Let's be clear about the situation: CC Mode does just too much
processing in refontification for current hardware to be able to scroll
smoothly through a buffer at normal auto-repeat speeds.  Setting
fast-but-imprecise-scrolling to non-nil is a handy workaround, but it
isn't good enough to make the scrolling appear to be smooth when one
holds down C-v.  I think (and hope) this is what you mean by
"stuttering".

The bug which I'm hoping to have fixed was that in the large struct in
Wireshark's function proto_register_rrc, the scrolling got slower and
slower as one got further into the struct.  On my machine, 80% of the
way through that struct, scrolling a single screen (62 lines) was taking
between four and five seconds, which was unacceptably slow.  With the
bug fix, this scrolling takes about 75 milliseconds, regardless of the
position in the struct.  This is apart from the first screen drawing in
the neighbourhood, which takes a little time to fill the new cache
entry.

Could you please confirm that you see the same uniformity in scrolling
speed anywhere inside a large struct, and that the speed is acceptably
close to instantaneous for a single scrolling operation.  Or do you see
something different?  Thanks!

Maybe we can close this bug relatively soon.

-- 
Alan Mackenzie (Nuremberg, Germany).