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

[Eli Zaretskii]

> Date: Thu, 13 Apr 2023 03:23:18 -0700
> From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
> Cc: emacs-devel@gnu.org
> 
> > > (The number 1.05 below is chosen to lower overhead of messages 50 times,
> > > from 5x to 0.1x.  It is related to log(10000)/0.05 ∼ 10000/50.)
> > 
> > Thanks, but does it indeed make sense to print these progress message
> > with logarithmically-increasing intervals?  Why not simply decimate
> > the messages by printing them every N words or so?  N could be
> > computed at the beginning of the command as function of the size of
> > the region to be spell-checked, assuming some suitable value of
> > average length of a word.  WDYT?
> 
> 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.

> Going logarithmic avoids all these complications.

But, as you say, the 1.05 factor was chosen by some kind of profiling
as well, no?

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