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: Sun, 26 Mar 2023 09:14:40 +0200 Message-ID: <5624c78c-c424-deec-2649-f11a5c149d22@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> <38eca973-0d1b-cd3b-1602-00d22c8c1afe@gmail.com> <83ileobu0t.fsf@gnu.org> <834jq8az83.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="7904"; 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 Sun Mar 26 09:15:29 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 1pgKbB-0001jP-Ai for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Mar 2023 09:15:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pgKan-00066F-5N; Sun, 26 Mar 2023 03:15:05 -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 1pgKal-000663-Br for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 03:15:03 -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 1pgKal-0007ft-0p for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 03:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pgKak-0004c8-Df for bug-gnu-emacs@gnu.org; Sun, 26 Mar 2023 03:15: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: Sun, 26 Mar 2023 07:15: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.167981489117703 (code B ref 62352); Sun, 26 Mar 2023 07:15:02 +0000 Original-Received: (at 62352) by debbugs.gnu.org; 26 Mar 2023 07:14:51 +0000 Original-Received: from localhost ([127.0.0.1]:43994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgKaY-0004bT-Hl for submit@debbugs.gnu.org; Sun, 26 Mar 2023 03:14:50 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:46888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pgKaW-0004bF-9t for 62352@debbugs.gnu.org; Sun, 26 Mar 2023 03:14:48 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id eg48so23652522edb.13 for <62352@debbugs.gnu.org>; Sun, 26 Mar 2023 00:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1679814882; 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=JH/BRlHZh9Yl/eXlNzjsX5ykAhjLwciZ5FuiW/y0hGk=; b=llBTRmi8aZQi/600nu8OCppoMWEyky1MLEjd6gB+EZRbmDgu3qic5zh6+dBix1RgCC ggr67RluJoEBytLh/aVxnSI8DqUncVEcoq7xFONHby8NBO4ZMsqJIC9RzwTBPNySI0Cz KyECnpDnr6tr62pPUt1DY+UajdqFtAmDT0MPzvxkH4ou9Tw1t2UFDdK0DzwE5Jg/F8jJ esKEoClzsEhdN+51ZWe+P0Z8913jkmbXqFTUT14z1hfawuW7vCZiNgthDejyO5hXfmik qJPq8E3yNNfr1sv/5p1WWjXH+EIcIIchBcdz3Jmq1MRrLz/g9tNgriYK65iqQuTMBx3e fogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679814882; 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=JH/BRlHZh9Yl/eXlNzjsX5ykAhjLwciZ5FuiW/y0hGk=; b=ScJP92cDIL9qbLnCNoO9qQJVSycbc1bi/KQNW9LYj0NLqdv6igPj+yrr+g/50FEDCI a79tjdfV/ygOJ1u/2rC3liZ/Muz54WVK3hhjEtjWSD6KXjs7unK5phpCAcBROfuxC4GH nRfCxMre+K+WFeg5A/kyVXTsBx6Azn+iDVC0VVFFoYdYO8DMM0J801i3hv6Nh8uir9rL inTFlDYVNFoyRULMJBAl3E4ZCmoTcFMKLtTaO/KzG7qKIPZwucASeW+EfGdNicBAFEZH n8ywet09bVhUePYdCBoG5wQUUN5lrsmyWH/lVvt4oSutYgZET7CdWn2ETxzhiSh0QR9C UqMQ== X-Gm-Message-State: AAQBX9cdqZak6VCLNmB3dHI5L3HpbrPN1FkxJIp6ts2GDQ3QubF+VDfG PfCttdhcFdSYe95+gR/0G5o= X-Google-Smtp-Source: AKy350Z8uaF/S1nJCAMUMdmkpy9QmKdIn9oXglhb7CSoV/yqNHzq4LxeaAZfteKwagB4f+DN2qpR+g== X-Received: by 2002:a05:6402:1055:b0:4ab:ec2:3cd1 with SMTP id e21-20020a056402105500b004ab0ec23cd1mr6929764edu.25.1679814882133; Sun, 26 Mar 2023 00:14:42 -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 n4-20020a5099c4000000b00501cc88b3adsm9257176edb.46.2023.03.26.00.14.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 26 Mar 2023 00:14:41 -0700 (PDT) Content-Language: sv-FI In-Reply-To: <834jq8az83.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:258657 Archived-At: On 3/26/23 06:55, Eli Zaretskii wrote: >> >> The problem is not there. The problem is that find_composition is only >> interested in the composition property, yet it scans all the properties >> linearly. > It doesn't scan linearly. It calls next-single-property-change, which > traverses the interval tree we use for storing text properties. > Please take a look at the implementation of > next-single-property-change in textprop.c. It finds the starting point by traversing the tree (presumably an O(log(number_of_properties)) operation (that's good), but then scans linearly. My example buffer has a different property for (almost) all characters, this means that this function will search the tree for ~500 elements to conclude that there is no such property around. And it does this operation for every single character visible in the window, or something like this. >> And it scans it for 500 characters. This file has a lot of >> properties, this means a lot of unnecessary and duplicated work (because >> it does this for each character displayed, or something like this). If >> the composition property had its own list, then this problem wouldn't exist. > If the composition property had its own data structure, Emacs would > need to search them both when it looks for a change in _any_ property > (something that happens quite a lot in other places), and handle > various combinations of hits in both data structures. That'd be a > significant complication for a small gain. If that's the case, then emacs could have a data structure which contains all the properties (like now), and one which points only to the composition properties. Yes, this is a complication, it will make emacs generally a little bit slower, but it would avoid freezes. But maybe this is not the correct solution. I have a feeling that this 500-character search area is not a good solution for the problem it tries to solve. Maybe it's a result of some optimization that was relevant a long time ago, but now it isn't, and it is actually a de-optimization if the buffer contains a lot of properties. A lot of people wouldn't care if emacs used a little more CPU power in general (as an example, during general editing, it would use 30% CPU instead of 20%), if this means that there is no stuttering. That's why people (me included) set the garbage collector threshold to a high value, because of the introduced micro-stuttering by the GC. But I'm not even sure that having more specialized search structures would actually slow down emacs in general. Maybe the net result would be that not only emacs won't freeze, but it would also become generally faster.