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: Sat, 16 Dec 2023 21:13:28 +0200 Message-ID: <83jzpeklk7.fsf@gnu.org> References: <76DF29CF-0B94-4405-BC8A-4CC80FCC88B5@gmail.com> <83plz6ksen.fsf@gnu.org> <2D9250E6-B7B6-4CF7-9B39-EB6796C77282@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="13327"; 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 Sat Dec 16 20:14:10 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 1rEa70-0003GU-HM for ged-emacs-devel@m.gmane-mx.org; Sat, 16 Dec 2023 20:14:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEa6h-0003bk-Pg; Sat, 16 Dec 2023 14:13:51 -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 1rEa6f-0003bX-2m for emacs-devel@gnu.org; Sat, 16 Dec 2023 14:13:49 -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 1rEa6e-0001uI-7M; Sat, 16 Dec 2023 14:13: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=prK+c2Cevn9wM2fSM5vICQZxV5NR2+LUmVBbmIDqZwA=; b=ampBJKi2nFaqJIhgs9AD BxVGtrQrrddTTtlAqXLnOZR4v7VAqfTG9eGHcQ12p+ZaBbxgjpo8oWAA2KGHj4MV1qMoo3SG7cUha qgcIj3/7WohZhOzWTXbBiYKkgAHLlgyh9eckcRHWwyONzEdSHTQOo6odXjQtH8/lTz7Zm4ycPfuRD vHcbeCFsh+NJ6yBAFlVsfaiZK9tvSHgOOBMHfPVrByrBA/WYOVsUBQpbNyuDUz7W8A6lk5ohOd+qZ fgRpjB8WX3VXGeRkUQDpoRet9IQT/8EcTi8/MFaRkNKPiNWGEdJLLxxRQc2eptlK03luATalkIHL6 zWoKpirMjCEOMA==; In-Reply-To: <2D9250E6-B7B6-4CF7-9B39-EB6796C77282@gmail.com> (message from JD Smith on Sat, 16 Dec 2023 13:54:40 -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:313882 Archived-At: > From: JD Smith > Date: Sat, 16 Dec 2023 13:54:40 -0500 > Cc: emacs-devel@gnu.org, > casouri@gmail.com > > >>  > > > > (I don't understand what was supposed to be shown in my MUA at this > > place; what I see is as single character U+FFFC.) > > Apologies; you’d think inline images could survive passage in 2023! These two images were included in the OP: > > https://private-user-images.githubusercontent.com/93749/289367869-b0d8ab4f-c231-4964-85ba-d9ecc20363b0.png > https://private-user-images.githubusercontent.com/93749/290972630-54f81ca6-4e4e-4943-a5a1-d8a949bd3c33.png I cannot view these images: my browser says there are errors, and if I try downloading them with wget, I get 404... > > Maybe the stuff you display uses some characters that make > > redisplay slower for reasons other than line-length? What kind of > > characters are used for showing these "undo-trees"? > > Nothing fancy, just characters from either one of these two sets (with faces applied): > > (defconst vundo-ascii-symbols > '((selected-node . ?x) > (node . ?o) > (horizontal-stem . ?-) > (vertical-stem . ?|) > (branch . ?|) > (last-branch . ?`))) > > (defconst vundo-unicode-symbols > '((selected-node . ?●) > (node . ?○) > (horizontal-stem . ?─) > (vertical-stem . ?│) > (branch . ?├) > (last-branch . ?└))) > > I just retried my test with the ascii-only symbols, and it resulted in a modest 17% speedup, but still >20s at 32K columns. Very strange. Profiling should point out the culprit, especially if you load the .el file (not .elc!) and then profile. > To confirm, it’s your understanding that functions like all those mentioned above (goto-char, looking at, delete-char, move-to-column, insert) should be agnostic w.r.t. the length of lines, for buffers of the same total character count? Yes. Emacs editing commands are largely unaware of lines, unless Lisp programs invoke functions that are sensitive to lines, like end-of-line etc. Buffer text is stored as a C string, it is not subdivided into lines. Only the display engine is sensitive to lines. > > Bottom line: I don't think I understand what causes your problems. > > The information presented is insufficient for even guessing the > > possible reasons. Please consider telling more. > > I did include a link to the short draw function itself; not sure if you saw that. And I demonstrated clearly (IMO of course) that the performance slowdown depends directly on the max column count of the displayed buffer. As a small bit of constructive feedback, this take (“insufficient for even guessing the possible reasons”) strikes me as uncharitable given this context. You must understand that I don't have time to study non-trivial code when such questions are posted. I spent 8 hours today reviewing and installing patches, merging the release branch to master, fixing bugs people reported over the last days, etc. So by "insufficient information" I meant what was presented explicitly, both here and in the discussion of the issue. My best suggestion so far is to profile the code; if you are certain you know which function is problematic, profile that after loading the code as .el file, and show the completely expanded profile. The profiles you've shown until now indicate that vundo--draw-tree is the hot spot, so loading it as a .el file and running "M-x profiler-start" followed by "M-x profiler-report" when it finishes should show the expensive parts. Another idea is to increase the GC threshold, in case what slows this down is the amount of garbage created by this code.