From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] 5x speedup of flyspell-buffer Date: Thu, 13 Apr 2023 13:32:11 +0300 Message-ID: <83wn2g3wes.fsf@gnu.org> References: <837cug5l18.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3750"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ilya Zakharevich Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 13 12:32:19 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pmuFX-0000mh-Cd for ged-emacs-devel@m.gmane-mx.org; Thu, 13 Apr 2023 12:32:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmuEh-0001jO-9G; Thu, 13 Apr 2023 06:31:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmuEf-0001ic-Nx for emacs-devel@gnu.org; Thu, 13 Apr 2023 06:31:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmuEf-00067V-1W; Thu, 13 Apr 2023 06:31:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=0F91O3vzPQDYFiaJcYVq6GHDTsfbzUVTxHxQLFfsVxY=; b=mptqjLp2bb0Q0NpgTfV1 fQw+TnfT5IIKhMSf8sWR84l3lCI9lE6VsLpXbPZmtW0j7CGracgBnC1fmpUu7kE4KekX7mc+FK0i/ niRSXRDaXC2XMqvmz81GOjyIdvf2H7eXtCb+cVEPh5iFyPmFOvywj1Q9uBNiNKpKLg1uxtyo4cKBQ vaO9oU2R/x52kNRY6kDvJBqdlODyy7xLICR2EX5UZ8XZyVw1Ak8atjNLXqbjlqRgThnWNjS0WxKy7 fIKStN5MrkC8mhwXUAKZcFdIJgtlSiBeT8UIo60oagRe8j89flf0xMhrIOxiUONH7Lvpu6BMYNf98 pb/zDW8iaHmpYQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pmuEe-0004MJ-Gq; Thu, 13 Apr 2023 06:31:24 -0400 In-Reply-To: (message from Ilya Zakharevich on Thu, 13 Apr 2023 03:23:18 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305294 Archived-At: > Date: Thu, 13 Apr 2023 03:23:18 -0700 > From: Ilya Zakharevich > 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?