bug#45320: 27.1; diff-refine performance regression

[Lars Ingebrigtsen <larsi@gnus.org>]

Achim Gratz <Stromeko@nexgo.de> writes:

> *** Hunks are now automatically refined by font-lock.
> To disable refinement, set the new user option 'diff-refine' to nil.
> To get back the old behavior where hunks are refined as you navigate
> through a diff, set 'diff-refine' to the symbol 'navigate'.
>
> The refinement is run synchronously and can't be interrupted.
>
> The used algorithm clearly has superlinear complexity with the size of
> the diff hunk.  I frequently use diff-mode for comparison of log files
> from compilations, which routinely creates large hunks and sometimes
> very large ones.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This isn't the common use case for showing diffs, so it sounds like you
should just alter the 'diff-refine' user option as described above.

> Auto-refinement of diff hunks should
>
> 1. be stopped
>
> a) after a customizable time threshold (personally I'd be OK with
>    something like 1s, but other folks may have less patience),
>
> b) when the user tries to move point (even small delays are annoying
>    when you really just want to scroll through the file),
>
> c) when C-g or the corresponding signal is issued.

The problem with  of these is that font-locking is done from
redisplay, and if you `C-g' something from those functions, it'll just
try to restart the fontification.  But...  I guess we could slap
something around `diff--font-lock-refined' to change the value
(buffer-locally) of diff-refine if the user hits `C-g' while it's
running?

> 2. not be attempted at all
>
> a) when the hunk size exceeds a customizable threshold,

That should be possible...

> b) when the diff in question has run into one of the performance
>    thresholds multiple times already.

I'm not sure that's practical.

Anybody have any other ideas here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no