bug#45320: 27.1; diff-refine performance regression

[Achim Gratz]

Lars Ingebrigtsen writes:
> 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.

The problem is caused by a change in defaults and whether or not the use
case seems common to you is besides the point.  The default used to be
no refinement and the change in default was done on the assumption that
the performance hit would generally not be bothersome.  As long as (GNU)
grep does have this clearly superlinear complexity characteristic that
simply isn't true (just for entertainment I've let Emacs hang while grep
finishes the refinement several times and it is not uncommon that I see
grep taking several minutes.  I think the longest I've kept it running
was way over one hour.

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

My go-to solution is to send USR2 to the emacs process, but that's
really not something I should ever need to do with an Emacs in standard
configuration.

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

The hunk size only factors into this due to the superlinear complexity in
the refinement.  It might be tricky to figure out a size that works
across all inputs since the structure of the hunk is also important.

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

Ideally all such external processes should run asynchronously (as a
"future") with a timeout.  If there is a timeout event, the user presses
C-g or point is moved to a different hunk before the result gets
delivered the process simply gets canceled, otherwise there is another
round of redisplay that is using the result.  I guess that caching previous
results would be quite useful at least in this particular case, so the
details of the implementation could become quite involved.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada