From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Newsgroups: gmane.emacs.bugs Subject: bug#62352: Very slow scroll-down-line with a lot of text properties Date: Sat, 25 Mar 2023 18:38:19 +0100 Message-ID: <38eca973-0d1b-cd3b-1602-00d22c8c1afe@gmail.com> References: <51545b85-029c-a6ff-f733-e486f261f6c0@gmail.com> <83355x7sx2.fsf@gnu.org> <08b5f766dd5d453016a7@heytings.org> <83sfdtcab8.fsf@gnu.org> <83h6u9c89f.fsf@gnu.org> <834jq9c4kb.fsf@gnu.org> <83pm8wby5e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29605"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.1 Cc: 62352@debbugs.gnu.org, gregory@heytings.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 25 18:39:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pg7rQ-0007Wl-5R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 25 Mar 2023 18:39:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pg7rH-0000g4-HP; Sat, 25 Mar 2023 13:39:16 -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 1pg7r9-0000fc-Cq for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 13:39:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pg7r4-0003Is-FW for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 13:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pg7r4-0007tj-96 for bug-gnu-emacs@gnu.org; Sat, 25 Mar 2023 13:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Mar 2023 17:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62352 X-GNU-PR-Package: emacs Original-Received: via spool by 62352-submit@debbugs.gnu.org id=B62352.167976590930314 (code B ref 62352); Sat, 25 Mar 2023 17:39:02 +0000 Original-Received: (at 62352) by debbugs.gnu.org; 25 Mar 2023 17:38:29 +0000 Original-Received: from localhost ([127.0.0.1]:43394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg7qX-0007ss-A5 for submit@debbugs.gnu.org; Sat, 25 Mar 2023 13:38:29 -0400 Original-Received: from mail-ed1-f45.google.com ([209.85.208.45]:44836) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pg7qV-0007se-Ru for 62352@debbugs.gnu.org; Sat, 25 Mar 2023 13:38:28 -0400 Original-Received: by mail-ed1-f45.google.com with SMTP id eh3so19913814edb.11 for <62352@debbugs.gnu.org>; Sat, 25 Mar 2023 10:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679765902; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=PxOyn8Z39qdqD3B4RQRzJHv3VlG3nZKofOvfDJScZbo=; b=fPOA2YPKamAjIhECAeobc2eC7H375coAkV+BhBzrxZRH21EYsomkfheeOlFDICXYdh cDMFJ687U9lrNweXuWd4kVN5ij9zJwd4xPbh7OSmNDchdwfvgMsHcDkxozPN9uMABj+j c4s6hCLhThJ01z1f6Ph/YSVDhWk6mz2ZP5dSXxIrjImwBiKyE4OvYaCzKTYMchlLM8Y8 8hasbzdB0ZgavKR2oHW8xE6efsqNRBehEX2THVjtFbPQrD98HzCAU3uQvO285l0AOrSp +FRD1+wlM/X1qG4arfXmA7luhB6Tq+Dp4RH2QjU1YvdmR2/HJWhmDqfA8LkNDd90k9MD yU5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679765902; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PxOyn8Z39qdqD3B4RQRzJHv3VlG3nZKofOvfDJScZbo=; b=HxAC23kYbfhXJPKsGJ7cQKmM4tzuivcSoRei8lqSyQTH0Sv5geWp35EzTTqT5BJLbh OyqJ9EY74iZJEN4TQVCZfG+PYvZoLCRkRO+/2DuteYqUk4kl011oqVdAOiuQnAqIB9T5 RCZkML7MNMXr4W7XCNUiTgnImdR4NqMWf9zhK9RZ2WVyH6mOE+nVSjVxvKrlOIsv23Gg wHs7NVnzDuaLwY9yiG8/oiqXNfy74bYBsX9k35CRkdHqdmPrcW3MdaKTlR/22pkZ101m F3ao+K9YMem06ZuZKuxLyErStwXQd5AcMOebbEnjSsCdIYRA3anDge+2h4E0oNcY8i21 +PYg== X-Gm-Message-State: AAQBX9cOev/aVa8invg68z/iYc8m8FYbOmezA+XOWM7cJ2Azyqt6KczU XZHAH1508WVmf+kC20wry8s= X-Google-Smtp-Source: AKy350b8izeA5FAVL/Yf2F8xV/4FvWTq/HPYSVTFggkMuNBFg/GzKndKYefRp5x6UNueOQTRGiK/4A== X-Received: by 2002:a05:6402:d3:b0:4fa:e1fd:5a30 with SMTP id i19-20020a05640200d300b004fae1fd5a30mr6482048edu.19.1679765901465; Sat, 25 Mar 2023 10:38:21 -0700 (PDT) Original-Received: from [192.168.8.4] (netacc-gpn-204-88-167.pool.yettel.hu. [5.204.88.167]) by smtp.gmail.com with ESMTPSA id x2-20020a50ba82000000b004fb30fc1dabsm12386220ede.96.2023.03.25.10.38.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Mar 2023 10:38:21 -0700 (PDT) Content-Language: sv-FI In-Reply-To: <83pm8wby5e.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:258607 Archived-At: On 3/25/23 17:20, Eli Zaretskii wrote: >> Properties don't appear out of thin air, emacs is the one who puts the >> properties to characters. So Emacs could build a parallel data structure >> which contains this information in a better searchable way. This data >> structure can be lazily constructed/updated, if it's needed. > It is not easy to maintain such a cache. It needs to be kept up to > date at all times, and discarded/recreated when no longer accurate. > Any Lisp program can in principle add or remove text properties at any > moment, even inside a hook called by the display engine itself, such > as fontification-functions. > > IOW, it is not as simple as you seem to think. I didn't meant to imply that it is easy. It is certainly not. But, tbh, while emacs is fluid most of the time, it can be very stuttery sometimes. In my experience, this is usually caused by some lisp code. But when it isn't, it is usually caused by some code in this area. When I profile emacs, these functions (next_property_change and similar) are usually on the top of the list. So it would make sense to optimize around this area. Not just because of this issue, but in general. I'm not necessarily suggesting a cache. Maybe it's better to actually always manage additional data structures. So, if a text property is added, it's not just set for the specific character area, but it will also modify search structures right away. So additional data structures were always in sync. Sure, it has some overhead. But if emacs does a lot of linear searches (and having a look at these functions, I see a lot of linear searches), this overhead will be quickly mitigated by the much faster searches. For example, if emacs had a list which only contained text segments with the composition property, the current 500-char area search will be much faster. I'd definitely trade some CPU time in a way that emacs will use some more CPU time in general (to manage additional data structures), but it will never freeze (because corner cases are handled much better). But maybe that's just me, others have different opinions about this. Anyways, this is not the best place to discuss this, and I also don't know too much about emacs's internals. My intuition is that these problems can be solved in faster way, that's all. >> Even, for my example problem, a simple >> "does-this-buffer-have-any-characters-with-composition-property" would >> be enough. > That would be a one-time condition. It could become false before the > next redisplay cycle. And checking this condition even once in a > large buffer with many text properties takes non-negligible time. I'm not sure I understand. If a composition text property is added to a character, then emacs would increase a buffer-local counter (I mean a counter at the C side, not a buffer-local lisp variable). If a composition text property is removed from a character, then emacs would decrease the buffer-local counter. And of course there are other events that modifies the value of the counter (char copy, delete, etc.). So this counter would always contain the number of composition characters in a buffer, or in other words, whether a buffer has a composition char or not. So, if find_composition sees that this counter is zero, it can return right away. I'm sure that this extra check won't take any significant CPU time. Why wouldn't this work, why does the redisplay cycle break this idea? (I'm not acutally suggesting this idea, of course, because it's just a bandaid instead of a proper solution. I'm just asking because I'm curious why this wouldn't work) > There's a performance problem, I agree. But as long as the design of > the display engine is what it is, I don't see how that can be helped, > in a way that will cope much better with the massive amount of face > properties as in these examples. Yeah, I understand this. This is what I meant in one of my previous comments: if this is a large work, then it makes sense to close this bug report, because maybe it's not worth fixing this. Too much work for a small gain. >> This is the file for which emacs freezed >> for 40 seconds, when I moved the point to the bottom, and pressed and >> hold Shift-up for 1-2 seconds. > Here it "freezes" for just 4 to 5 seconds, not 40. Ok, cool, at least you can reproduce the problem now. I'm not sure what causes the large difference (4/5 sec vs. 40 sec). Maybe window size, or something else. But it doesn't matter too much. The point is, that for some buffers, scroll-down-line can cause some freezing. (In my real life code, emacs freezes for about a second, so it's not too bad. But it's annoying if I hit by this too often, that's why I reported this issue)