Re: [PATCH] 5x speedup of flyspell-buffer

[Ilya Zakharevich]

On Thu, Apr 13, 2023 at 01:32:11PM +0300, Eli Zaretskii wrote:
> > Without profiling, how to find out “how much overhead is tolerable to
> > the user”?!
> 
> Since you say the change you propose speeds up by a factor of 5, just
> setting N = 5 should do approximately the same, no?  I'd actually go
> with N = 10 for a good measure.

Nope.  My solution decreases THE OVERHEAD 50 times.  This SPEEDS UP
the whole brouhaha ∼5x (since the overhead was 4x). 

> > Going logarithmic avoids all these complications.
> 
> But, as you say, the 1.05 factor was chosen by some kind of profiling
> as well, no?

Sure — but the logarithmic solution is not sensitive to the
system/operator’s specifics. 

> > P.S.  BTW, there is very little need to lock the UI.  On my (very old
> >       and slow) system, these 10,000 misspellings are reported in 300ms
> >       (even though aspell is cygwin — read “slow” — one).  After this
> >       list of misspellings is swallowed, the rest of marking can be
> >       done asynchronously, via timers.
> 
> If you intend to do this asynchronously, I think a relevant question
> is why would you need to do that for the entire buffer?  When doing
> this synchronously, the answer is clear, but doing it asynchronously
> means you don't really care when will it end.  So in that case,
> perhaps a better idea would be to spell-check only the stuff in the
> window, and update that as the window is scrolled to expose more of
> the text, like jit-lock.el does for fontifications?

The simple answer: this does not work.

Observe “how well implemented” it is now — after decades of many
people trying!  (I have seen something like tens of discussions of
people attempting something like this.  The latest attempt I have seen
uses POLLING!)

Ilya

P.S.  This seems (probably) very similar to jit-lock vs lazy-lock.  In my
      experiments, jit-lock is/was “an order of magnitude worse”.  (Do
      not remember the details)

      So I need to do through a lot of fracas to upgrade to each new
      version of Emacs…

P.P.S.  On my system, the minimal overhead of flyspell-large-region (for
        small regions) is ~0.6sec.  Not suitable for every update of a
        buffer.

        (This is ON TOP of “other problems of implementation”.)