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

[Alan Mackenzie <acm@muc.de>]

Hello again, Ravine.

Sorry it's taken a little while to reply.  I've been preoccupied with
another bug in the meantime.

On Sat, Dec 19, 2020 at 09:58:48 +0530, Ravine Var wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > 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".

> Yes, that's what I meant. These are my keyboard settings:

> $ xset q | grep "repeat rate"
>   auto repeat delay:  200    repeat rate:  30

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

> I still see the behavior that you have described.

Just to be sure what you're seeing, I take it you see this:
(i) Move point to a long way through the big struct in
proto_register_rrc, e.g. with C-u 2  M->;
(ii) Perform a single C-v, to ensure the caches are filled, and wait for
redisplay to complete;
(iii) Perform one or more C-v.  These each take several seconds before
redisplay is complete.

I do not see this happening on my machine.  Except that's not quite
true.  If I switch to M-x c++-mode in the file (e.g. by mistake), I see
the above slowdown.  I have a fix prepared for that, too.

> With the patch, scrolling becomes slower and slower rapidly and the
> screen locks up (using emacs -Q).

By "scrolling becomes slower", do you mean (1) that the time for an
isolated single full screen scroll becomes longer, the further you are
through that struct?  Or do you mean (2) that on auto-repeat of the C-v
or PageDown key, the scrolling becomes slower?

If you mean (1), I would ask you, yet again, to produce a profile,
following steps (i), (ii), and (iii) above, doing M-x profiler-start
after step (ii), then M-x profiler-report after step (iii).

If you mean (2), from emacs -Q without enabling
fast-but-imprecise-scrolling, then you are just seeing the normal
expected, but unfortunate behaviour of Emacs: Emacs will not redisplay a
screen as long as there is keyboard input unprocessed, but Emacs is
spending its time fontifying the intermediate screens (which are not
about to be displayed) as part of processing that input.  30 characters
per second is faster than CC Mode can paint a single screen.

For problem (2) I recommend, again, enabling
fast-but-imprecise-scrolling.

> I tested with a single C file containing just the function
> proto_register_rrc().

I have been testing with this, too.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).