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.bugs Subject: bug#56682: Fix the long lines font locking related slowdowns Date: Sun, 24 Jul 2022 09:52:51 +0300 Message-ID: <83czdvgfy4.fsf@gnu.org> References: <837d46mjen.fsf@gnu.org> <174616cd5c33bfc14b1f@heytings.org> <837d44jr4p.fsf@gnu.org> <83bktghrn0.fsf@gnu.org> <87v8rnc2wp.fsf@gmail.com> <8335erizqh.fsf@gnu.org> <83r12bhgfo.fsf@gnu.org> <83pmhvhg7g.fsf@gnu.org> <83o7xfhfqw.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29584"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca, visuweshm@gmail.com To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 24 08:55:13 2022 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 1oFVWC-0007ZY-TP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Jul 2022 08:55:13 +0200 Original-Received: from localhost ([::1]:39398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFVWB-0003nm-Ec for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 24 Jul 2022 02:55:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50476) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFVV4-0002iy-PE for bug-gnu-emacs@gnu.org; Sun, 24 Jul 2022 02:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56983) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFVV4-0004Px-CQ for bug-gnu-emacs@gnu.org; Sun, 24 Jul 2022 02:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oFVV4-0003np-77 for bug-gnu-emacs@gnu.org; Sun, 24 Jul 2022 02:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 24 Jul 2022 06:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56682 X-GNU-PR-Package: emacs Original-Received: via spool by 56682-submit@debbugs.gnu.org id=B56682.165864559714554 (code B ref 56682); Sun, 24 Jul 2022 06:54:02 +0000 Original-Received: (at 56682) by debbugs.gnu.org; 24 Jul 2022 06:53:17 +0000 Original-Received: from localhost ([127.0.0.1]:46732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFVUK-0003mg-Pv for submit@debbugs.gnu.org; Sun, 24 Jul 2022 02:53:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oFVU4-0003ll-VZ for 56682@debbugs.gnu.org; Sun, 24 Jul 2022 02:53:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53656) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFVTz-0004Em-6N; Sun, 24 Jul 2022 02:52:55 -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=x1eP+F/bUpZULRDsmUGFsXeML4Zg4HiW319KXNv1jXc=; b=HmWbBeK4v6FQDtdH7O4K 5AjJYCSG50rTeWdGh+mi/QpDkzMsGx8srgus/QcIlpjOkZ8XyAxsSQLLjHHvsm711GVc07TSjOwlf +4ZiXiZHccGXEob2g0d4dRfDPDlKhY2fun/eEjd6dg1dWIPMnKQDPYfhcVhn5sY34nbZk8vBswThx hL7UyNwYo65a2zOKfshtp39/c4HgY9Lz6e4URvQ8L9kn0gTa0iRrI6LyUQlfisbs/u052oGOkpn/f mxlxxSnO7Q5t/urqqL83xI7ZaI9+PqHHxyIeV7IhnuXQX8P9ZhdCQzknpHFqb92FNbgUJg0to2JP+ f9+CF+ABS7U/hw==; Original-Received: from [87.69.77.57] (port=2626 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 1oFVTw-000329-RW; Sun, 24 Jul 2022 02:52:54 -0400 In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sun, 24 Jul 2022 08:16:33 +0200) 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" Xref: news.gmane.io gmane.emacs.bugs:237808 Archived-At: > From: Gerd Möllmann > Cc: 56682@debbugs.gnu.org, gregory@heytings.org, monnier@iro.umontreal.ca, > visuweshm@gmail.com > Date: Sun, 24 Jul 2022 08:16:33 +0200 > > And another BTW: I was never 100% certain if the interval tree is > really always balanced because it didn't use an algorithm that I > knew and could recognize. AFAIU, we balance on-the-fly (see find_interval, which calls balance_possible_root_interval). > "frequent" changes of faces certainly have an effect on iterator > performance. It stops, looks up properties again to determine the > next stop pos, does what has to be done for current properties... To be more accurate: changes in text properties that are not relevant to display basically affect the iterator performance in only one way: they make the search for the next change in _relevant_ properties more expensive. See the last part of compute_stop_pos for the gory details. In a nutshell, we check one by one the intervals following the interval of the current iterator position, until we find an interval whose values for one or more of the properties of interest to redisplay are different. When we find one such interval, it is guaranteed to have changes only in the text properties that are of interest to redisplay, but the search could take more time if there are many text properties that are not interesting, because there are more intervals to check. Btw, it might be interesting to measure the effect of enlarging TEXT_PROP_DISTANCE_LIMIT, currently 100 character positions, on the performance. Looking at the code, it is not clear to me whether it could affect the performance in any significant ways, but maybe I'm wrong.