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: Mitigating the long-lines penalty in vundo Date: Sun, 17 Dec 2023 20:07:47 +0200 Message-ID: <83a5q8k8i4.fsf@gnu.org> References: <76DF29CF-0B94-4405-BC8A-4CC80FCC88B5@gmail.com> <83plz6ksen.fsf@gnu.org> <2D9250E6-B7B6-4CF7-9B39-EB6796C77282@gmail.com> <83jzpeklk7.fsf@gnu.org> <85EA63D3-24FE-4FA7-9DEC-B60835F96986@gmail.com> <838r5tl23k.fsf@gnu.org> <186F0A42-25E1-4A12-B6A1-F5B0F1465447@gmail.com> 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="25449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, casouri@gmail.com To: JD Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 17 19:08:54 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 1rEvZO-0006Tg-0h for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Dec 2023 19:08:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEvYg-00033I-Sz; Sun, 17 Dec 2023 13:08:10 -0500 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 1rEvYd-000335-TS for emacs-devel@gnu.org; Sun, 17 Dec 2023 13:08:08 -0500 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 1rEvYd-0004Nz-Km; Sun, 17 Dec 2023 13:08:07 -0500 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=a2oU421fClOR3H3PjgOJmuPWjeBABuN0GWT2UdZ3/wc=; b=Vby6pcFwCUCOMkNZTFe/ XuhhwFV2aFLdtIhgnBlpPqQpFI/q55X+bijUQIDegcpaVJUB0DclllADzAA38fDtS5ePcrMjiwxw0 JTbEujSA9LxJPmAgPHOe5EPkERr1ZvMvwq4qRxCe/z1MeNrSz7x6aHdc03elk0Clmp3eHPkYRtHHU 6l2p90yrxBmsBWzOkGSB4uFi5HJk1QFPH2YHs/g2M4XhjKu8+GwkeUcU+HNbYT1PkSRmnKtJbsAlY bXPwDGMI4LT9qr2rNlT/e5MQ/Dv5hEzYZnF0Xe6iehyGAMku6MhcVyz7t9AgBduPthG2V6CfoJ6WP zJpCVNdG6FNFjg==; In-Reply-To: <186F0A42-25E1-4A12-B6A1-F5B0F1465447@gmail.com> (message from JD Smith on Sun, 17 Dec 2023 12:49:27 -0500) 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:313938 Archived-At: > From: JD Smith > Date: Sun, 17 Dec 2023 12:49:27 -0500 > Cc: emacs-devel@gnu.org, > casouri@gmail.com > > That said, with long lines (>10-20K columns, say) visible, the problem remains that overall Emacs is > mildly but noticeably less responsive, in the mini-buffer, in other buffers, etc., until the vundo buffer is > hidden. Perhaps that’s just the minimum penalty paid for such long lines. Long lines with faces and overlays, I should say. > The current-column docs do say: > > In a buffer with very long lines, the value will be an approximation, > because calculating the exact number is very expensive. > > The "very long lines" case happens when the line's length exceeds the > long-line-threshold, which in your case it most probably doesn't > (unless you lower long-line-threshold considerably). So this part of > the doc string is not relevant to your problem. > > I was only referring to the “very expensive” part. The "very expensive" part is also only when lines are around long-line-threshold. Again, not your case. > Yes. The problem is that vundo.el uses 'display' properties _a_lot_, > and those slow down current-column, because each time it sees a > 'display' property whose value is a string, it needs to extract the > property value and calculate the width of that string, to account for > its width on display. > > That would have indeed been a good explanation for the additional slowness, but in fact vundo does > not use 'display properties: I do see 'display' properties being used: (defun vundo--highlight-node (node) "Highlight NODE as current node." (unless vundo--highlight-overlay (setq vundo--highlight-overlay (make-overlay (1- (vundo-m-point node)) (vundo-m-point node))) (overlay-put vundo--highlight-overlay 'display (vundo--translate "●")) (overlay-put vundo--highlight-overlay 'face 'vundo-highlight) ;; Make current node’s highlight override last saved node’s ;; highlight, should they collide. (overlay-put vundo--highlight-overlay 'priority 2)) (move-overlay vundo--highlight-overlay (1- (vundo-m-point node)) (vundo-m-point node))) > Indeed this was a vundo problem in that there was no need to call current-column over and over for > each node. But the basic slowness of current-column remains, so unless there are low-hanging > improvements to be made there, algorithms that need frequent column calculations would need to try > other approaches. Lisp programs are not supposed to need frequent column calculations, certainly not several times on the same line. > * Current column is reasonably fast counting long lines of plain text — 175ms total to compute each > column at 6000 nodes spread over 18K columns. > * current-column is quite slow counting unicode characters: about 21x slower than the ascii > equivalents. Perhaps this is because unicode chars can have non-standard widths, so emacs > needs to do some additional checks? No. I can understand why non-ASCII characters are somewhat slower, since each one of them is several bytes, not just one, and we convert the multibyte representation into a codepoint on the fly. But 21-fold slowdown sounds excessive. > * But this isn’t the full story, because current-column is also (separately) quite slow counting plain > characters with attached faces: 33x slower than the fast case. This one seems less intuitive to me. > Can faces also (in principle) alter the character width (like italic for example)? When buffer text has faces (or any other text properties, really) current-column uses a slower algorithm, because the faster one will yield incorrect results. > * Combining these two (unicode chars with alternating faces) is the worst case — 43x slower than > the fast case of unadorned plain chars. This was vundo’s case. Then vundo is better redesigned to avoid such massive reliance on current-column. There's one more factor to consider here: current-column always starts from the beginning of the line. If vundo needs to call current-column many times on the same line, it loses because it each time starts from BOL, in effect throwing away the results of the previous calculation. This wastes CPU cycles. It might be better to use sum char-width values of individual characters instead.