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 09:28:31 +0200 Message-ID: <838r5tl23k.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> 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="24362"; 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 08:29:49 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 1rElav-0006Cf-C4 for ged-emacs-devel@m.gmane-mx.org; Sun, 17 Dec 2023 08:29:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rElZy-0008HB-V9; Sun, 17 Dec 2023 02:28:50 -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 1rElZw-0008Gw-HH for emacs-devel@gnu.org; Sun, 17 Dec 2023 02:28:48 -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 1rElZw-0008B3-4n; Sun, 17 Dec 2023 02:28:48 -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=Z9VcRUm0EdXJbnWywURwn4E4kiuTh1uCojINRa0FJdg=; b=iwJABoqt3tbaA4vqY9Ml XTUQsAyj78aYC/Edn9ymLRoXKW2Ls5uYjaqg3Dz+/QVWjYmly9eIl/T444aEYfCG/kzeFBoUByGEf MBNm6w0WNxIaFRRcZwTcWAuYdqo4ZcMGlvk0Ck+nkZXy6Jc1/nHB4yay/PJn+ykMQxYwUCwquHOlW hrDDj6MVKdX0in6UqHPlF5XKXxG6S6yKOvEnXFhqMFPJ073ic5NmDdRY8Xpb7ssoGTCrq/D+HjJBc wFBhj1s4cwQTIJbepo9hrpw9DvDVLU/SJuUM0M9JYc3eXB/6TYi5sxlz0DHCBlCR45J41beJr1lqO y9H3KWKxaiFezw==; In-Reply-To: <85EA63D3-24FE-4FA7-9DEC-B60835F96986@gmail.com> (message from JD Smith on Sat, 16 Dec 2023 17:00:36 -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:313901 Archived-At: > From: JD Smith > Date: Sat, 16 Dec 2023 17:00:36 -0500 > Cc: emacs-devel@gnu.org, > casouri@gmail.com > > I tried again from a clean session with eval-buffer’d vundo.el. The profiler for 10,000 edits (no undos) > reports a very odd result: > > 1799 95% - command-execute > 1799 95% - call-interactively > 1799 95% - funcall-interactively > 1799 95% - eval-expression > 1799 95% - eval > 1799 95% - save-current-buffer > 1797 95% - vundo > 1797 95% - let > 1756 93% - vundo-1 > 1756 93% - save-current-buffer > 1756 93% - let > 1756 93% - save-current-buffer > 1756 93% - vundo--refresh-buffer > 1756 93% - save-current-buffer > 1756 93% - let > 1651 87% - if > 1649 87% - vundo--draw-tree > 1649 87% - let* > 1649 87% - while > 1649 87% - let* > 1640 86% - let > 1560 82% - max > 1560 82% 1- > 71 3% - if > 71 3% - let > 71 3% - if > 65 3% + insert > 9 0% - rx-to-string > 7 0% + rx--translate > 1 0% + cons > 2 0% + if > 1 0% + progn > 1 0% vundo--put-node-at-point > 1 0% vundo--node-timestamp > 2 0% + eq > 105 5% + let* > 41 2% + let > 87 4% + ... > > Looking closer, the only relevant thing in draw-tree is (1- (current-column)). Adding that to my elp list > and... we have found the principal culprit (here with 10K edits): > > vundo--draw-tree 1 9.65838 9.65838 > current-column 10001 9.124152 0.0009123239 > > `current-column’ is apparently pretty expensive here (~1ms). Yes, I think current-column is the culprit here. > 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 just tested it in a temp buffer with width 10K, and it’s much less expensive (60-100µs). Perhaps the > text properties on each node character (containing the defstruct node object) slows current-column > down even further. 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. This is basically an algorithmic problem in vundo.el: since the width of each string that vundo--translate is fixed and can be computed in advance, vundo.el could count the columns itself (by adding those known widths), instead of asking current-column to measure the width of those strings over and over and over again. Alternatively, instead of using 'display' properties, vundo.el could insert the characters produced by vundo--translate directly into the buffer, which would allow current-column to work at its usual speed. > So it is a long-lines problem of a sort, just not display related. I disagree. it's a problem with too many 'display' properties in the buffer, which is not recommended for more than one reason. I suggest to rethink this design.