bug#29889: 27.0.50; Slow visual selection

[Eli Zaretskii]

> From: Sujith <m.sujith@gmail.com>
> Cc: 29889@debbugs.gnu.org
> Date: Sat, 30 Dec 2017 07:06:05 +0530
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> > Confirmed.  Additional info:
> >
> > This happens also on the emacs-26 branch and in the 26.0.90 pretest,
> > but not in Emacs 25.2.
> 
> I checked out the 'emacs-25.2' tag and the issue happens there also.

You are right.  It turns out the issue all but disappears in an
optimized build; once I rebuilt Emacs 25.3 without optimizations, I
see this in that version as well.

However, I don't seem to be able to see the problem in a -nw session,
or maybe the slowness in non-GUI frames is just below the threshold of
keeping up with the keyboard auto-repeat rate.

Starting with Emacs 25.1, we switched to using an overlay for showing
the region, so the prime suspect at this point is the relatively
expensive redisplay when buffer overlays have changed since the
previous redisplay, especially in a buffer with many text properties
(produced by font-locking).  E.g., I see that with region highlighted,
every C-f causes a full redisplay of the window, because all the other
redisplay optimizations are disabled.

> To get a valid starting point which could be seen as a 'good' commit
> for git-bisect, I tried to go back in the tree. I went up to Jun-1-2016
> and then I ran into build errors. But the issue was present at that
> point too.

This sounds consistent with the hypothesis that the overlay-based
implementation of region highlighting is the trigger.

> Anything else which I could do to help ?

Run Emacs under 'perf' (or build with C-level profiling), and show the
C-level profile while moving the cursor with region highlighted?  That
should tell whether my hypothesis above holds any water, and if not,
point out some other suspects.

Thanks.