Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 13:47:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 26 09:47:42 2024 Received: from localhost ([127.0.0.1]:38840 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sMSzt-0000kg-M4 for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:47:41 -0400 Received: from mout02.posteo.de ([185.67.36.66]:35609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sMSzs-0000kT-8h for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:47:40 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1A98C240103 for <71644 <at> debbugs.gnu.org>; Wed, 26 Jun 2024 15:47:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719409652; bh=9/WoiVtPKig6J9HtQph+yQG8sHN0nZ0Sf1etSMHMoek=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=BcpTa/PInL29nToVMDz8q1MYHfv/ztzDRhDeW1rOlVTFgbRfvFGjWUbcyLI+4Wd7n z+nMIBGyYdDWh12WX4zXhg8Cnfs6Zk+e94Ui0WUvNmoI34tmUl5klvOhc1VU3w/lmv aA0HNWz+WIuwzLAND2bfapv9zP3g9klB23lR8579mmqbusAKGKlHXBp85u6ZdwZyD9 w/ORdwI0HZGv2kr1RmxJag7pcvoz3wIeER7/hU8jrrCiTlpZlVTrSFBGzAE/1ZCPlE XCXfHmPXZNP/Y4sDsP1NsipeNEACnQJ8fCpMyKWza8YWQ8rbFp7o2FMkcg5QCI9U1C zNO8PclU2HfkQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W8NLB5s6Mz9rxB; Wed, 26 Jun 2024 15:47:30 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN> <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN> Date: Wed, 26 Jun 2024 13:49:09 +0000 Message-ID: <87r0cjddbe.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: Eli Zaretskii <eliz@HIDDEN>, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: > Yes, definitely. The threshold is at about N/100 where N is the number > of markers/headings. But why 100? Maybe because bytepos - best_below_byte > 5000 and distance += BYTECHAR_DISTANCE_INCREMENT; (BYTECHAR_DISTANCE_INCREMENT = 50) Then, (/ 5000 50) ; -> 100. In other words, for (tail = BUF_MARKERS (b); tail; tail = tail->next) loop is roughly bound to (min number-of-markers 100)-ish repetitions. So, once the number of markers exceeds 100, there is no more scaling with the marker number. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 13:30:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 26 09:30:38 2024
Received: from localhost ([127.0.0.1]:38812 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sMSjN-0000LX-Uk
for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:30:38 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16531)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sMSjM-0000L8-F1
for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 09:30:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 76589441754;
Wed, 26 Jun 2024 09:30:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719408626;
bh=4FAkVjSxhbukgFWKSw6JX8VN7l67fwdgcna8OGgEDp0=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=SsxTcke7xaYIklB9E4qymh5Zb1+RXkuxvuxOh7s0bjgaPbo09XwkgvqkvcZaI302x
uvgQZqVrDxYorwy7yml7Un3gP0stj8LgHehnqQ4WRhtBmbz5a8umivavq2ZLzYZ0Hm
VB6Ls1xFzTrF1vCMZeQNanbF3VH/viR48GjuanAXOXhr0xJh+pZPOo0W1AsBEbdf90
Yq9kdDRoGKP/L5uGQlHuzBbytrGvo9fSfx9qvyytsU/PvSUoANki5Tn8OSB0K1ORT7
dUjagaKzsKaDMUjq6lP5Wy5Rh1Y0esSCQttinRp7s1AbP6gb/+hA1EtKngmXdCfXAj
ctFvX78s+h1Yg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BCDA0440EE8;
Wed, 26 Jun 2024 09:30:26 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8953C1207CF;
Wed, 26 Jun 2024 09:30:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <861q4k9bjh.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 26 Jun
2024 14:41:06 +0300")
Message-ID: <jwvtthfzvhm.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
<87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
<jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN>
Date: Wed, 26 Jun 2024 09:30:25 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.083 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: yantar92@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>> - The markers histogram is weirdly flat.
>> - The markers histogram seems to have a threshold around 800
>> I can't explain. It seems directly related to the buffer size, tho:
>> with a file half the size, I get half as many markers (40k) and
>> a threshold in the histogram around 400.
>> - The number of times we consider exactly 1 marker is probably "too
>> high" because the C code happens to look at the first marker before
>> checking if it's necessary.
>
> The fact that it's related to buffer size is probably because your
> test buffer is basically N >> 1 repetitions of the same pattern, so
> whatever Org does it does that N times, where N is directly
> proportional to the buffer size.
Yes, definitely. The threshold is at about N/100 where N is the number
of markers/headings. But why 100?
> How many markers are there in this buffer during the experiment where
> you produced the histogram you've posted? My guess is 48400 or
> thereabouts?
It's the first number in the list (the one before `:markers`): 80044
> Also, what were the buffer positions where you tried your editing
> operations? In particular, where those positions distributed evenly
> over the buffer?
I focused on edits on the first copy and on the last copy.
> And questions to Ihor: what are the reasons Org creates these markers?
> In particular, is there any way to know or guess whether these markers
> will be distributed more-or-less evenly over the buffer text, or
> clustered near some specific positions? Also, does Org move these
> markers frequently, or do they stay put once created?
They're created by `consult-outline` rather than by Org.
There's one marker per heading, AFAICT, and so they're very
evenly spread (and presumably ordered last-to-first in the `markers`
list).
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 12:41:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 26 08:41:24 2024 Received: from localhost ([127.0.0.1]:38749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sMRxk-0007Nu-GZ for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:41:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sMRxi-0007Nb-6v for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:41:23 -0400 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 <eliz@HIDDEN>) id 1sMRxa-0000MA-Jo; Wed, 26 Jun 2024 08:41:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yfGduc2t0YktytLOhaxSlsEAvr7RyAsw9FKmHom6ocU=; b=iJvugcLjP8nP 785XmT9BAnOWta+akSXUS20tPPEndzqJKr3xqeC5ri2p1y6dL/Sapzv+o9Gnun7EfeIysXKbYL1Ul Oca9sqp9qgwCQTuDHTBtyVwuwFjcN4gNx14BjEFKQvQ6kISDyxulMG3bmc0ItqEJ5+dxtxd96FQEX wRmTM6/PjhRlduc3YIpDyrcqUPRKcEgY5MUy3+2Pc4xFmKVNNP1QW29jQC3Sw5m9rP13/y7VnmMkA meiq0G3wZ4bbHP8gT/8EESK6E6QXZKGGUwY9YklCX6LGOYwNGpY5EOu42Z0reyV0nIoWNRFMjZpkh sYxHHcwoG1UvGMACeW8Vfw==; Date: Wed, 26 Jun 2024 15:41:11 +0300 Message-Id: <86tthf98rc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Mitchell <mitchellahren@HIDDEN> In-Reply-To: <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN> (message from Mitchell on Tue, 25 Jun 2024 21:53:42 -0600) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost> <86jzid9lbj.fsf@HIDDEN> <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: yantar92@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Mitchell <mitchellahren@HIDDEN> > Date: Tue, 25 Jun 2024 21:53:42 -0600 > Cc: Ihor Radchenko <yantar92@HIDDEN>, monnier@HIDDEN, 71644 <at> debbugs.gnu.org > > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > > > > ... So if you could come up with a change to try on > > > > top of Org 9.6 that would change it back to use overlays for folding, > > > > we could try that and see if the slowdown goes away, and take it from > > > > there. > > > > > > (setq org-fold-core-style 'overlays) ; before Org is loaded > > > > Thanks. Mitchell and Stefan, can you try this? > > I tested setting org-fold-core-style to 'overlays before loading org and unfortunately it did not help the > slowness in the test org buffer. These are the two lines I tried in separate tests: > > (setq org-fold-core-style 'overlays) > (customize-set-variable 'org-fold-core-style 'overlays) Thanks, I guess it means this theory eats dust.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 12:34:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 26 08:34:30 2024 Received: from localhost ([127.0.0.1]:38739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sMRr4-0007DW-33 for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:34:30 -0400 Received: from mout02.posteo.de ([185.67.36.66]:54589) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sMRr2-0007DB-80 for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 08:34:28 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 43AD7240103 for <71644 <at> debbugs.gnu.org>; Wed, 26 Jun 2024 14:34:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719405259; bh=+uMHnMZivwfdkeQCyklvXEWVHUuHHxBmQJaD4ZJ+FQ0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=X5wb+jrnn5vy+NDblylJtTRHrFGPtQY7Za6+OxMSErxabjHnJA5CfH8hWchbLbIi0 hvfFLFksX37Ra64vPAEstfHZP87e+ZVNhkJX4kSn9ILIrxhW7pqrj/dEkenRV6u9Ve b9S/nB0iXaMqFAQEeXCY2BezC9pLNNyC3X/NXI5iYQcf1OeKtnPYEBucrNBphbFE/s C4TUB9obZpdJkzro0DIGoF39caPkkzgGKWd2RIvR+bXOIbusYuJ3b9tM91YDMWQ7LS P2Q8Gpkz8VISTP+TsDBauTnHey3skkYtOMUUFqctrLb+rB6CEZGlNYI4i06VO0PPIO ltyCzDd94ImbQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W8Ljh1rKrz9rxK; Wed, 26 Jun 2024 14:34:16 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <861q4k9bjh.fsf@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> <861q4k9bjh.fsf@HIDDEN> Date: Wed, 26 Jun 2024 12:35:55 +0000 Message-ID: <87zfr7lw44.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > And questions to Ihor: what are the reasons Org creates these markers? > In particular, is there any way to know or guess whether these markers > will be distributed more-or-less evenly over the buffer text, or > clustered near some specific positions? Also, does Org move these > markers frequently, or do they stay put once created? In this particular case, with the reproducer we are using here, Org does not create markers. `councel-outline' does - for every headline in buffer with marker pointing to the beginning of each headline. These markers are distributed as headlines do. Org mode may also create markers in some scenarios. Also at headlines, but not necessarily _all_ headlines. org-agenda creates markers for every headline that is displayed in agenda (matches agenda search criterion). org-refile creates markers for each top level heading (by default). org-goto creates markers for each heading down to level 5. Org mode does not move these markers frequently, except markers created by agenda, when a heading is killed/yanked via org-cut-special/org-paste-subtree or org-refile commands. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 11:41:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 26 07:41:20 2024 Received: from localhost ([127.0.0.1]:38686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sMR1c-0005vf-8q for submit <at> debbugs.gnu.org; Wed, 26 Jun 2024 07:41:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sMR1a-0005vS-4P for 71644 <at> debbugs.gnu.org; Wed, 26 Jun 2024 07:41:19 -0400 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 <eliz@HIDDEN>) id 1sMR1R-0005Fq-IO; Wed, 26 Jun 2024 07:41:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0G7gk4U4H8PhiIJsiM1TFVYg/3UKEOvFBv+P+vcn66s=; b=hmgED/e4SdkJ LfL0de3DPvlqnzj9Nsi40Yl0LIEXlyttllVxwJ6ReTiJOqlruwR/h+IblGlHHp5iu/QVIL53nAgUY H7z7CdmswcWT/EPufNagoJAhRztEF0GGCIh4QJmcOBZMuMZdCd+mJLmF2FFTpeL9+FhLcQayPdDEj zjYWzcspm/IynxVIFZeEG77//Yk5kyn05HhY9NcBmcldqEuncWDVIvg5joDzfWh/8BM1G4jUXVS1B 5RK8kYrLGaht8egmyv5Lh0rOkJCOOOkhlGB6bjQoTq4Bgvgmy2HR7RObPTfXrPnHf/Tl+Uu9J9J5o YB2B+4r/s5OVoyBo8T9L2g==; Date: Wed, 26 Jun 2024 14:41:06 +0300 Message-Id: <861q4k9bjh.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 25 Jun 2024 16:54:44 -0400) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: yantar92@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > 71644 <at> debbugs.gnu.org > Date: Tue, 25 Jun 2024 16:54:44 -0400 > > I instrumented the bytes<->chars routines to try and keep track of what > happens there. This gives me a histogram showing how many times the > conversion routines consulted N markers as well as another histogram > telling me how many times those routines scanned between M*100B and > (M+1)*100B of text. > Oh and it gives me the number of markers in the buffer as well (the > histogram is not buffer-local, but there's basically only one buffer in > that session). > > The result are below (followed by the actual code). > There are several odd things in there: > > - The markers histogram is weirdly flat. > - The markers histogram seems to have a threshold around 800 > I can't explain. It seems directly related to the buffer size, tho: > with a file half the size, I get half as many markers (40k) and > a threshold in the histogram around 400. > - The number of times we consider exactly 1 marker is probably "too > high" because the C code happens to look at the first marker before > checking if it's necessary. The fact that it's related to buffer size is probably because your test buffer is basically N >> 1 repetitions of the same pattern, so whatever Org does it does that N times, where N is directly proportional to the buffer size. Questions: How many markers are there in this buffer during the experiment where you produced the histogram you've posted? My guess is 48400 or thereabouts? Also, what were the buffer positions where you tried your editing operations? In particular, where those positions distributed evenly over the buffer? And questions to Ihor: what are the reasons Org creates these markers? In particular, is there any way to know or guess whether these markers will be distributed more-or-less evenly over the buffer text, or clustered near some specific positions? Also, does Org move these markers frequently, or do they stay put once created?
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 03:55:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 23:55:30 2024 Received: from localhost ([127.0.0.1]:37893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sMJkn-0007Xi-Ls for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 23:55:29 -0400 Received: from mail-ed1-f54.google.com ([209.85.208.54]:45146) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mitchellahren@HIDDEN>) id 1sMJkl-0007XV-Gp for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 23:55:28 -0400 Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-57d1679ee83so6809986a12.2 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 20:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719374059; x=1719978859; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YMXsh1+ogi/369VcBAnmBG3nxkbr45b3YDzSvGl1ahQ=; b=gGBH+ok84iQwDPcQPqz64GfeGP3r2srCQP55bS4s8xZt6qn4Ul/6W3zISF7z+rVa6K RBftciiz/Ou8GtccobXsrMzUjhZhAG1NT6pZDDby9vfiL7glmFSct4n9oNRd6ofnHwJ2 PizrsPvfTwvSTKPSq5VZaEhaFx6kVrp3r7mTeC8RhzfNmmu3U4D5V8GE0wgMbOtdyo1c 9yypcQnJpUCRM8FrtmauXzWlchNvZaZiglP1HAe2fMt7y6RudxbeDaVcM9weYr/yHg6Z Hlp0kEQus2tdcL7D2b22Tp9NWefvzKM3jEEwCG77SnTbnEEO1THi5HCqqxhOao/ye4F3 ADlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719374059; x=1719978859; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YMXsh1+ogi/369VcBAnmBG3nxkbr45b3YDzSvGl1ahQ=; b=nDeErUGmGO9CG59DEbl9aghMf9kX44p2IK67UYYz67+cV3eG/lLYzPvYczoNF9O2IT YdNQ3CyKJs82a7dck0QWQFkLmCX9zO+Ci2vTFKuEOXt6XpsRBChd3ebM6SDl8wF3L9SR Pge3G2N/gAEC1LmJG6f4ffrfIcNXfwKcQKMPLSDYqCbkJUKuTLWWBtxRl7t2rc36cQGm JvDceVMe/HyLQaJpulLvXRF67VHhZgUkh/xruPInjGd4/QMAj8gCW0XGT64zYzRqzVQ2 /qK6B2NKLAeBtHY3A+6zx6OklEaicSUr6iVYjp4g/sqyJ5xLCsUtGkIAdLSBnqILYhGl Qosw== X-Forwarded-Encrypted: i=1; AJvYcCUNebQaZgaRQtoSeAmvXICq5CVHi/WB3RDZI4L4dD+TtIOCloyeKBbMc0vDJNEbWnNM21ejSbCFeKiotIr6SksX0fxP2zU= X-Gm-Message-State: AOJu0YzcNNNmfbdzxR5I2gXmpXIKJtn4L2K5TnnFbI43NpT2Y1P/Mgnc vJdIQjbhKg2XznIuYuVPD2prMCjdyUg1reVR3v7balX4hcimvFRBIy/lS5dO9ZflLFUXirimYU6 6jewk8Z4vggzyyKUxnNsLDxgljgw= X-Google-Smtp-Source: AGHT+IEtjaxsAKbjMJh4SguLy8BOJo3muAwaDuuwB1Os+6qfGRavrS5DCPCW3v8QH8QqCJ0E8/oRfk2Ars/7SB9AGcM= X-Received: by 2002:a50:d795:0:b0:57c:c019:a9f6 with SMTP id 4fb4d7f45d1cf-57d457f60f9mr6988922a12.32.1719374059188; Tue, 25 Jun 2024 20:54:19 -0700 (PDT) MIME-Version: 1.0 References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost> <86jzid9lbj.fsf@HIDDEN> In-Reply-To: <86jzid9lbj.fsf@HIDDEN> From: Mitchell <mitchellahren@HIDDEN> Date: Tue, 25 Jun 2024 21:53:42 -0600 Message-ID: <CAOQwW=bYKO7qbf176EtH1VY5y-5T+orTGNtPWgqWW4o5Sn8KLQ@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000008b821061bc2f865" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71644 Cc: Ihor Radchenko <yantar92@HIDDEN>, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000008b821061bc2f865 Content-Type: text/plain; charset="UTF-8" > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > > ... So if you could come up with a change to try on > > > top of Org 9.6 that would change it back to use overlays for folding, > > > we could try that and see if the slowdown goes away, and take it from > > > there. > > > > (setq org-fold-core-style 'overlays) ; before Org is loaded > > Thanks. Mitchell and Stefan, can you try this? I tested setting org-fold-core-style to 'overlays before loading org and unfortunately it did not help the slowness in the test org buffer. These are the two lines I tried in separate tests: (setq org-fold-core-style 'overlays) (customize-set-variable 'org-fold-core-style 'overlays) --00000000000008b821061bc2f865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"> >=20 > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>>= writes:<br> >=20 ><br> >=20 > > ...=C2=A0 So if you could come up with a change to try on<br> >=20 > > top of Org 9.6 that would change it back to use overlays for fold= ing,<br> >=20 > > we could try that and see if the slowdown goes away, and take it = from<br> >=20 > > there.<br> >=20 ><br> >=20 > (setq org-fold-core-style 'overlays) ; before Org is loaded<br> >=20 <br> >=C2=A0 =C2=A0 Thanks.=C2=A0 Mitchell and Stefan, can you try this?<div>= =C2=A0</div><div>I tested setting=20 org-fold-core-style to 'overlays before loading org and unfortunately i= t did not help the slowness in the test org buffer. These are the two lines= I tried in separate tests:<br></div><div><br></div><div>(setq org-fold-cor= e-style 'overlays)</div><div>(customize-set-variable 'org-fold-core= -style 'overlays)</div></div></div> --00000000000008b821061bc2f865--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 21:25:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 17:25:19 2024
Received: from localhost ([127.0.0.1]:37719 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sMDf4-000742-PE
for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:25:19 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21675)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sMDcS-000702-7V
for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:25:09 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 49FC3804BC;
Tue, 25 Jun 2024 16:54:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719348884;
bh=2mwNLdLwe79GliepBjpnMAu4xT60BAd0JgNplx8k3No=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=EOwVnAMJqfxCf8gX4SDqgHNDDVhRmPItqmFygSK57CZ5CxmQ2uffifW0yFl8BiBBG
M1nVPG5/3aTlNvyMqm3XuK7q1cADKsEt1mXHmbP1HsB/u2UYahUivzk0YpF4tIWYDp
nq7ANmkce8yrUDeJXcxfIcX43kqiOcdHM/bDRH3o/1GE1+dH7wF96zjFVzkv1l0fgL
SVSQyzK5LDIz2tgI4lNm8qMd1AP+0ho1I3YzFgxM85Drse/fAczOVGMCGpFPpd55OB
xkBKoKJLSS5Qq1RCbEYJNt4iu3mBs7mfoIRWQkNNAjq6DLBX5SkXMspA53ryoP/h5l
Y3y4bqp/M6W4w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9C0D78027D;
Tue, 25 Jun 2024 16:54:44 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8658B120635;
Tue, 25 Jun 2024 16:54:44 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
of "Mon, 24 Jun 2024 23:07:32 -0400")
Message-ID: <jwv5xtwzs7t.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
<87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
Date: Tue, 25 Jun 2024 16:54:44 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.931 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain LONGWORDS 2.035 Long string of long words
X-SPAM-LEVEL:
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: > One other thing I notice: If I use Emacs-29 but with
Org-9.5.5
(i.e., the > version included in Emacs-28.2) the recipe doesn't show the
slowdown. One more thing: when I use Mitchell's recipe, sometimes buffer edits
are immediate and sometimes they're not (I mean, when following the recipe
exactly, it's not immediate, but if I do things slightly [...]
Content analysis details: (1.8 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror)
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
1.8 LONGWORDS Long string of long words
-0.0 T_SCC_BODY_TEXT_LINE No description available.
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.8 (/)
> One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
> version included in Emacs-28.2) the recipe doesn't show the slowdown.
One more thing: when I use Mitchell's recipe, sometimes buffer edits are
immediate and sometimes they're not (I mean, when following the recipe
exactly, it's not immediate, but if I do things slightly differently and
sometimes after doing other(?) things, it's immediate again).
When I'm in the "state" where editing is not
immediate, it seems to apply only to edits done right before or right
after a header: edits elsewhere (e.g. within some paragraph) are
still "instant".
Oh, and typing text at the end of a header seems to get me out of that
state, somehow (and I don't know how to get back into that state, tho
it sometimes happen).
BTW, my test case is now a large (26MB, 640kLines) Org file consisting of a=
long
repetition of:
* asdgasgasdfgsd=E9adfgasdgafg
=20=20=20=20
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh
=20=20=20=20
** sf na;l bnsdkh bsadlfv asdl fkbasldfv alsfkg v
=20=20=20=20
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh asdfadfkh
asdfadfkh asdfadfkh
I instrumented the bytes<->chars routines to try and keep track of what
happens there. This gives me a histogram showing how many times the
conversion routines consulted N markers as well as another histogram
telling me how many times those routines scanned between M*100B and
(M+1)*100B of text.
Oh and it gives me the number of markers in the buffer as well (the
histogram is not buffer-local, but there's basically only one buffer in
that session).
The result are below (followed by the actual code).
There are several odd things in there:
- The markers histogram is weirdly flat.
- The markers histogram seems to have a threshold around 800
I can't explain. It seems directly related to the buffer size, tho:
with a file half the size, I get half as many markers (40k) and
a threshold in the histogram around 400.
- The number of times we consider exactly 1 marker is probably "too
high" because the C code happens to look at the first marker before
checking if it's necessary.
(80044 :markers
((0 16) (1 3290720) (2 28912) (3 34427) (4 30479) (5 71089) (6 29858)
(7 29855) (8 29953) (9 30156) (10 30251) (11 30185) (12 30999)
(13 30270) (14 30530) (15 30332) (16 30175) (17 30278) (18 30187)
(19 30316) (20 29698) (21 29760) (22 29674) (23 29695) (24 29682)
(25 29689) (26 29699) (27 29835) (28 30483) (29 30455) (30 30444)
(31 30313) (32 29666) (33 29696) (34 29739) (35 29781) (36 29694)
(37 29726) (38 29722) (39 29729) (40 29721) (41 29800) (42 29846)
(43 29751) (44 29775) (45 29780) (46 29782) (47 29788) (48 29869)
(49 29891) (50 29811) (51 29823) (52 29834) (53 29817) (54 29833)
(55 29901) (56 29927) (57 29854) (58 29836) (59 29856) (60 29843)
(61 29835) (62 29918) (63 29928) (64 29851) (65 29858) (66 29857)
(67 29859) (68 29854) (69 29934) (70 29907) (71 29859) (72 29848)
(73 29859) (74 29859) (75 29875) (76 29916) (77 29904) (78 29865)
(79 29840) (80 29867) (81 29857) (82 29853) (83 29948) (84 29887)
(85 29861) (86 29852) (87 29850) (88 29866) (89 29880) (90 29935)
(91 29881) (92 29862) (93 29843) (94 29858) (95 29857) (96 29892)
(97 29931) (98 29878) (99 29856) (100 29848) (101 29855) (102 29856)
(103 29904) (104 29931) (105 29866) (106 29867) (107 29849)
(108 29843) (109 29876) (110 29906) (111 29917) (112 29859)
(113 29862) (114 29851) (115 29852) (116 29867) (117 29910)
(118 29922) (119 29848) (120 29862) (121 29858) (122 29837)
(123 29873) (124 29922) (125 29910) (126 29852) (127 29864)
(128 29852) (129 29852) (130 29866) (131 29916) (132 29928)
(133 29833) (134 29863) (135 29864) (136 29844) (137 29864)
(138 29923) (139 29923) (140 29842) (141 29854) (142 29864)
(143 29844) (144 29882) (145 29907) (146 29921) (147 29856)
(148 29838) (149 29864) (150 29873) (151 29854) (152 29925)
(153 29906) (154 29844) (155 29854) (156 29858) (157 29866)
(158 29885) (159 29917) (160 29888) (161 29860) (162 29831)
(163 29865) (164 29874) (165 29888) (166 29907) (167 29887)
(168 29862) (169 29844) (170 29850) (171 29880) (172 29887)
(173 29929) (174 29861) (175 29864) (176 29849) (177 29843)
(178 29880) (179 29909) (180 29916) (181 29853) (182 29864)
(183 29852) (184 29840) (185 29898) (186 29894) (187 29919)
(188 29845) (189 29864) (190 29858) (191 29850) (192 29880)
(193 29908) (194 29914) (195 29842) (196 29860) (197 29860)
(198 29854) (199 29891) (200 29903) (201 29931) (202 29847)
(203 29865) (204 29874) (205 29860) (206 29892) (207 29913)
(208 29921) (209 29860) (210 29850) (211 29872) (212 29877)
(213 29888) (214 29924) (215 29945) (216 29875) (217 29884)
(218 29892) (219 29903) (220 29892) (221 29960) (222 29931)
(223 29884) (224 29877) (225 29898) (226 29919) (227 29927)
(228 29973) (229 29964) (230 29925) (231 29902) (232 29923)
(233 29936) (234 29929) (235 29999) (236 29948) (237 29920)
(238 29913) (239 29917) (240 29938) (241 29948) (242 29994)
(243 29930) (244 29928) (245 29893) (246 29461) (247 29304)
(248 29906) (249 29983) (250 29929) (251 29922) (252 29909)
(253 29917) (254 29930) (255 29947) (256 30002) (257 29913)
(258 29928) (259 29919) (260 29908) (261 29927) (262 29978)
(263 29977) (264 29914) (265 29921) (266 29921) (267 29914)
(268 29924) (269 29963) (270 29998) (271 29903) (272 29921)
(273 29928) (274 29903) (275 29931) (276 29978) (277 29978)
(278 29908) (279 29921) (280 29923) (281 29926) (282 29920)
(283 29969) (284 29987) (285 29899) (286 29919) (287 29930)
(288 29922) (289 29918) (290 29978) (291 29976) (292 29911)
(293 29911) (294 29930) (295 29920) (296 29918) (297 29979)
(298 29977) (299 29918) (300 29904) (301 29928) (302 29929)
(303 29920) (304 29986) (305 29961) (306 29916) (307 29911)
(308 29921) (309 29932) (310 29931) (311 29991) (312 29942)
(313 29924) (314 29902) (315 29922) (316 29940) (317 29934)
(318 29982) (319 29940) (320 29926) (321 29913) (322 29921)
(323 29928) (324 29936) (325 30000) (326 29920) (327 29928)
(328 29915) (329 29915) (330 29930) (331 29959) (332 29983)
(333 29918) (334 29924) (335 29920) (336 29913) (337 29927)
(338 29960) (339 29991) (340 29911) (341 29922) (342 29928)
(343 29907) (344 29931) (345 29966) (346 29984) (347 29909)
(348 29921) (349 29924) (350 29919) (351 29925) (352 29965)
(353 29989) (354 29901) (355 29921) (356 29930) (357 29917)
(358 29917) (359 29979) (360 29981) (361 29913) (362 29909)
(363 29934) (364 29914) (365 29920) (366 29972) (367 29984)
(368 29908) (369 29914) (370 29930) (371 29931) (372 29914)
(373 29990) (374 29959) (375 29914) (376 29913) (377 29927)
(378 29926) (379 29932) (380 29968) (381 29964) (382 29921)
(383 29908) (384 29925) (385 29938) (386 29911) (387 29995)
(388 29946) (389 29920) (390 29913) (391 29925) (392 29928)
(393 29940) (394 29990) (395 29928) (396 29928) (397 29907)
(398 29919) (399 29938) (400 29948) (401 29979) (402 29929)
(403 29922) (404 29917) (405 29917) (406 29932) (407 29941)
(408 29998) (409 29915) (410 29930) (411 29923) (412 29912)
(413 29927) (414 29966) (415 29979) (416 29912) (417 29927)
(418 29925) (419 29916) (420 29920) (421 29955) (422 30000)
(423 29901) (424 29927) (425 29932) (426 29907) (427 29921)
(428 29974) (429 29978) (430 29910) (431 29923) (432 29929)
(433 29922) (434 29918) (435 29965) (436 29987) (437 29899)
(438 29923) (439 29932) (440 29926) (441 29912) (442 29974)
(443 29978) (444 29909) (445 29919) (446 29930) (447 29922)
(448 29914) (449 29973) (450 29979) (451 29920) (452 29908)
(453 29932) (454 29929) (455 29908) (456 29988) (457 29959)
(458 29922) (459 29915) (460 29923) (461 29928) (462 29923)
(463 29993) (464 29940) (465 29928) (466 29908) (467 29926)
(468 29930) (469 29930) (470 29982) (471 29940) (472 29930)
(473 29919) (474 29917) (475 29926) (476 29934) (477 29998)
(478 29920) (479 29932) (480 29917) (481 29921) (482 29924)
(483 29953) (484 29985) (485 29916) (486 29932) (487 29920)
(488 29915) (489 29923) (490 29908) (491 29377) (492 28865)
(493 29336) (494 29924) (495 29905) (496 29917) (497 29966)
(498 29982) (499 29907) (500 29927) (501 29922) (502 29913)
(503 29915) (504 29965) (505 29987) (506 29903) (507 29923)
(508 29928) (509 29909) (510 29911) (511 29975) (512 29981)
(513 29915) (514 29911) (515 29926) (516 29914) (517 29912)
(518 29968) (519 29984) (520 29910) (521 29912) (522 29932)
(523 29921) (524 29908) (525 29990) (526 29955) (527 29922)
(528 29909) (529 29923) (530 29920) (531 29926) (532 29966)
(533 29962) (534 29927) (535 29906) (536 29923) (537 29924)
(538 29911) (539 29993) (540 29944) (541 29926) (542 29911)
(543 29921) (544 29920) (545 29936) (546 29988) (547 29930)
(548 29930) (549 29905) (550 29917) (551 29926) (552 29944)
(553 29979) (554 29931) (555 29924) (556 29911) (557 29915)
(558 29924) (559 29937) (560 29998) (561 29917) (562 29928)
(563 29925) (564 29902) (565 29921) (566 29964) (567 29977)
(568 29918) (569 29925) (570 29921) (571 29910) (572 29914)
(573 29953) (574 29998) (575 29907) (576 29925) (577 29930)
(578 29897) (579 29917) (580 29972) (581 29976) (582 29916)
(583 29921) (584 29927) (585 29912) (586 29914) (587 29963)
(588 29989) (589 29903) (590 29919) (591 29930) (592 29914)
(593 29908) (594 29974) (595 29980) (596 29911) (597 29913)
(598 29928) (599 29912) (600 29912) (601 29973) (602 29981)
(603 29918) (604 29910) (605 29922) (606 29923) (607 29906)
(608 29986) (609 29963) (610 29922) (611 29911) (612 29917)
(613 29922) (614 29921) (615 29991) (616 29944) (617 29930)
(618 29904) (619 29916) (620 29926) (621 29928) (622 29980)
(623 29948) (624 29926) (625 29917) (626 29907) (627 29922)
(628 29932) (629 30000) (630 29924) (631 29928) (632 29915)
(633 29907) (634 29922) (635 29953) (636 29987) (637 29918)
(638 29926) (639 29918) (640 29905) (641 29921) (642 29954)
(643 29995) (644 29911) (645 29928) (646 29922) (647 29901)
(648 29917) (649 29966) (650 29986) (651 29915) (652 29921)
(653 29920) (654 29909) (655 29915) (656 29965) (657 29991)
(658 29907) (659 29923) (660 29924) (661 29905) (662 29911)
(663 29975) (664 29989) (665 29913) (666 29911) (667 29924)
(668 29910) (669 29912) (670 29972) (671 29988) (672 29908)
(673 29914) (674 29924) (675 29921) (676 29908) (677 29994)
(678 29959) (679 29916) (680 29911) (681 29919) (682 29920)
(683 29926) (684 29972) (685 29964) (686 29927) (687 29902)
(688 29919) (689 29924) (690 29911) (691 29997) (692 29952)
(693 29920) (694 29909) (695 29917) (696 29920) (697 29936)
(698 29992) (699 29932) (700 29930) (701 29903) (702 29913)
(703 29926) (704 29944) (705 29987) (706 29929) (707 29924)
(708 29909) (709 29911) (710 29924) (711 29941) (712 30002)
(713 29915) (714 29930) (715 29917) (716 29902) (717 29921)
(718 29970) (719 29979) (720 29914) (721 29925) (722 29917)
(723 29910) (724 29914) (725 29959) (726 30000) (727 29907)
(728 29921) (729 29926) (730 29897) (731 29917) (732 29976)
(733 29982) (734 29908) (735 29845) (736 29275) (737 28476)
(738 28898) (739 29693) (740 29989) (741 29897) (742 29915)
(743 29924) (744 29912) (745 29908) (746 29980) (747 29974)
(748 29907) (749 29909) (750 29922) (751 29912) (752 29914)
(753 29975) (754 29975) (755 29914) (756 29902) (757 29920)
(758 29921) (759 29910) (760 29988) (761 29957) (762 29914)
(763 29907) (764 29915) (765 29920) (766 29925) (767 29993)
(768 29938) (769 29922) (770 29898) (771 29916) (772 29924)
(773 29930) (774 29984) (775 29938) (776 29922) (777 29911)
(778 29907) (779 29920) (780 29934) (781 30000) (782 29918)
(783 29924) (784 29909) (785 29907) (786 29920) (787 29959)
(788 29981) (789 29914) (790 29795) (791 21494) (792 8509) (793 804)
(794 804) (795 800) (796 800) (797 800) (798 717) (799 323)
(800 200) (801 202) (802 200) (803 200) (804 172) (805 26) (5533 1)
(5548 1) (26958 1) (26974 1) (48384 1) (48400 1))
:distance
((0 26807330) (1 5518) (2 941) (3 160056) (4 2) (5 87) (6 25) (8 2)
(9 2) (10 7) (11 1) (12 22) (13 1) (15 7) (28 1) (30 4) (32 5)
(35 7) (39 3) (40 1) (42 5) (45 4) (48 2) (49 3) (51 1) (52 1)
(54 22) (55 7) (82 1) (2762 1) (2772 1) (13478 1) (13485 1)
(24191 1) (24198 1)))
diff --git a/lisp/subr.el b/lisp/subr.el
index d9df8d1a458..1e9c768fdfe 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -6968,6 +6968,22 @@ internal--format-docstring-line
(error "Unable to fill string containing newline: %S" string))
(internal--fill-string-single-line (apply #'format string objects)))
=20
+(defun bytechar--stats ()
+ (unless (hash-table-p internal--bytechar-marker-counts)
+ (setq internal--bytechar-marker-counts (make-hash-table)))
+ (unless (hash-table-p internal--bytechar-distance-counts)
+ (setq internal--bytechar-distance-counts (make-hash-table)))
+ (require 'map)
+ (list (internal--count-markers)
+ :markers
+ (mapcar (lambda (x) (list (car x) (cdr x)))
+ (sort (map-into internal--bytechar-marker-counts 'alist)
+ #'car-less-than-car))
+ :distance
+ (mapcar (lambda (x) (list (car x) (cdr x)))
+ (sort (map-into internal--bytechar-distance-counts 'alist)
+ #'car-less-than-car))))
+
(defun json-available-p ()
"Return non-nil if Emacs has libjansson support."
(and (fboundp 'json--available-p)
diff --git a/src/marker.c b/src/marker.c
index d220dd82692..623065de3f7 100644
--- a/src/marker.c
+++ b/src/marker.c
@@ -133,6 +133,28 @@ CHECK_MARKER (Lisp_Object x)
CHECK_TYPE (MARKERP (x), Qmarkerp, x);
}
=20
+static void
+bytechar_stats (int marker_count, ptrdiff_t distance)
+{
+ if (HASH_TABLE_P (bytechar_marker_counts))
+ {
+ Lisp_Object key =3D make_fixnum (marker_count);
+ Lisp_Object oldcount =3D Fgethash (key, bytechar_marker_counts, Qnil=
);
+ Lisp_Object newcount
+ =3D make_fixnum (FIXNUMP (oldcount) ? 1 + XFIXNUM (oldcount) : 1);
+ Fputhash (key, newcount, bytechar_marker_counts);
+ }
+
+ if (HASH_TABLE_P (bytechar_distance_counts))
+ {
+ Lisp_Object key =3D make_fixnum (distance / 100);
+ Lisp_Object oldcount =3D Fgethash (key, bytechar_distance_counts, Qn=
il);
+ Lisp_Object newcount
+ =3D make_fixnum (FIXNUMP (oldcount) ? 1 + XFIXNUM (oldcount) : 1);
+ Fputhash (key, newcount, bytechar_distance_counts);
+ }
+}
+
/* When converting bytes from/to chars, we look through the list of
markers to try and find a good starting point (since markers keep
track of both bytepos and charpos at the same time).
@@ -164,6 +186,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t cha=
rpos)
ptrdiff_t best_above, best_above_byte;
ptrdiff_t best_below, best_below_byte;
ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL;
+ int marker_count =3D 0;
=20
eassert (BUF_BEG (b) <=3D charpos && charpos <=3D BUF_Z (b));
=20
@@ -198,6 +221,7 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t cha=
rpos)
=20
for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)
{
+ marker_count++;
CONSIDER (tail->charpos, tail->bytepos);
=20
/* If we are down to a range of 50 chars,
@@ -215,6 +239,10 @@ buf_charpos_to_bytepos (struct buffer *b, ptrdiff_t ch=
arpos)
Scan, counting characters, from whichever one is closer. */
=20
eassert (best_below <=3D charpos && charpos <=3D best_above);
+ if (!NILP (bytechar_marker_counts))
+ bytechar_stats (marker_count,
+ min (charpos - best_below, best_above - charpos));
+
if (charpos - best_below < best_above - charpos)
{
bool record =3D charpos - best_below > 5000;
@@ -321,6 +349,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
ptrdiff_t best_above, best_above_byte;
ptrdiff_t best_below, best_below_byte;
ptrdiff_t distance =3D BYTECHAR_DISTANCE_INITIAL;
+ int marker_count =3D 0;
=20
eassert (BUF_BEG_BYTE (b) <=3D bytepos && bytepos <=3D BUF_Z_BYTE (b));
=20
@@ -350,6 +379,7 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
=20
for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)
{
+ marker_count++;
CONSIDER (tail->bytepos, tail->charpos);
=20
/* If we are down to a range of 50 chars,
@@ -365,6 +395,9 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t byt=
epos)
/* We get here if we did not exactly hit one of the known places.
We have one known above and one known below.
Scan, counting characters, from whichever one is closer. */
+ if (!NILP (bytechar_marker_counts))
+ bytechar_stats (marker_count,
+ min (bytepos - best_below_byte, best_above_byte - bytepos));
=20
if (bytepos - best_below_byte < best_above_byte - bytepos)
{
@@ -759,22 +792,23 @@ DEFUN ("set-marker-insertion-type", Fset_marker_inser=
tion_type,
return type;
}
=20
-#ifdef MARKER_DEBUG
-
/* For debugging -- count the markers in buffer BUF. */
=20
-int
-count_markers (struct buffer *buf)
+DEFUN ("internal--count-markers", Fcount_markers, Scount_markers, 0, 0, 0,
+ doc: /* Return the number of markers in the current buffer. */)
+ (void)
{
int total =3D 0;
struct Lisp_Marker *tail;
=20
- for (tail =3D BUF_MARKERS (buf); tail; tail =3D tail->next)
+ for (tail =3D BUF_MARKERS (current_buffer); tail; tail =3D tail->next)
total++;
=20
- return total;
+ return make_fixnum (total);
}
=20
+#ifdef MARKER_DEBUG
+
/* For debugging -- recompute the bytepos corresponding
to CHARPOS in the simplest, most reliable way. */
=20
@@ -804,4 +838,18 @@ syms_of_marker (void)
defsubr (&Scopy_marker);
defsubr (&Smarker_insertion_type);
defsubr (&Sset_marker_insertion_type);
+ defsubr (&Scount_markers);
+
+ DEFVAR_LISP ("internal--bytechar-marker-counts",
+ bytechar_marker_counts, doc: /* Hihi */);
+ bytechar_marker_counts =3D Qnil;
+
+ DEFVAR_LISP ("internal--bytechar-distance-counts",
+ bytechar_distance_counts, doc: /* Hoho */);
+ bytechar_distance_counts =3D Qnil;
+
+ DEFVAR_INT ("internal--bytechar-distance-increment",
+ bytechar_distance_increment,
+ doc: /* Haha */);
+ bytechar_distance_increment =3D 50;
}
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 21:15:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 17:15:27 2024
Received: from localhost ([127.0.0.1]:37712 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sMDVY-0006qF-ID
for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:15:27 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:32985)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sMDRG-0006jZ-3I
for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 17:15:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 70A6D8092E;
Tue, 25 Jun 2024 17:02:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719349326;
bh=0y0Zy5kTjvwVSW6UtOfjWYqDuw9PaJieDDsPSSUNBhM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=OVnFJxTJ8sGqatU/uG8IC++YXG9AeGGvmlaqlClvVkXzNmGkbkEojUmpbUqCNsXfX
LyJ0Va0TxMzpzaRX9Su9RxsSW63uf9WUsn6A2fwghyNK5Wr0D/alBTWEH/PjV5TmBd
P+dfXg8EsVc9Mg6Y3R+RRBQyaKfGCykWNlOhLrB+DRLBsBG+PVmnvrT0BTS+EVCW1E
FBxYV/R3Lc2tpQ+q9ghzawTXXWeJk2PCObN7T+x3iAVeyrAcGrzU5DpcmnS65RUOk3
km61mrmDF7RnTtU4WRE2sREQXiXGcpoUxUkmZOvHSecMSIZw20yEZQj+tDFrpAuix2
ClKW67fY+GsMA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 067CA8014E;
Tue, 25 Jun 2024 17:02:06 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E7BDB1205EF;
Tue, 25 Jun 2024 17:02:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
Jun 2024 14:10:23 +0000")
Message-ID: <jwvzfr8ybyj.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
<87wmmhgjao.fsf@localhost>
Date: Tue, 25 Jun 2024 17:02:05 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.099 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Yup. I _do not_ propose my patch to be merged.
> (BTW, we should probably merge this bug and bug#63040 where I first
> shared this patch - just to demonstrate the problem and discuss possible
> solutions)
FWIW, I'm not sure it's exactly the same problem yet.
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 14:23:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 10:23:46 2024 Received: from localhost ([127.0.0.1]:37521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sM75G-0005ed-7I for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 10:23:46 -0400 Received: from mout02.posteo.de ([185.67.36.66]:39793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sM75B-0005eL-US for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 10:23:45 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7C7A6240101 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 16:23:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719325412; bh=1nlarY+0s4sSc/fPNWCJd4vffrXl6UkQ1fbiOg2ltVs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Mh3M6aH9X5X5YNvZ9iin7xKyk81bq6P/lC+YG1VDX7KRjULigYqDcVZfqG7+L2THl +ATjHN3EiekQQuHFNSE0LeIP21dvdK2NuoHPq2kIvUa8t7rwGInIoQaKdnoayqG8pi KTHoSx5rPfO5kqRxD/sF+aFLmD8BV5G9qOABdjzkvJC6IdOhGvAxaFZQvZJnAQ+MDa KkYziM2ShQ2fASLrOspE4yfLm8bX8ikHbdO/gKjTE5TZdrEvNdkHW4IOmMuBgcGFeB tmVRsQPMUyfdU+MSd0BbN8T9lb+kMLTK2YN0Odu55F0NdHRMSte+amqJaM1BmWLNA7 z7Tl0ASfq/7fA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W7nBC2NCpz9rxK; Tue, 25 Jun 2024 16:23:31 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <86jzid9lbj.fsf@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost> <86jzid9lbj.fsf@HIDDEN> Date: Tue, 25 Jun 2024 14:25:06 +0000 Message-ID: <87cyo55ccd.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > P.S. For some reason, Stefan's email server rejects my mails "due to > abuse", I hope it could be fixed soon. Same for me.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:57:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 09:57:49 2024 Received: from localhost ([127.0.0.1]:37493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sM6g8-0004yV-Lp for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:57:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sM6g6-0004yH-Fd for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:57:47 -0400 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 <eliz@HIDDEN>) id 1sM6fz-0000Ip-1x; Tue, 25 Jun 2024 09:57:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KxruSHo4ACUi0W+1atzIYADcEfA7CmuHETld4hnL3AE=; b=Bq+yzu7DXYld DKIyg0n+06O/DbefRDFbjoiuMLwheNMcziGHkn6qYZJKd/MdQZacqb8sj4XUJ7jzpRp09lqSHo0LA BJJvlgwWztu9V1nXye6gVP9U/1g2nWuQjK1KIpanuf7M52U8hFz9zhdnYdptDR4+zUQEOqFC0gV9l 5nrzDKxqH++EELJOY1gNReAOyNah6zQGHp8TRA8Lv5HSianE8Ft/sDFmDw4Fi3Y4BdZoetmrPPwP6 1K+dHEt/xB6qqZaIUBs0SeBu7PZ04iS+1Q5I8ifN809HFkeJYyuli/k6LAvbaIITs4h4A0Wu0pg1+ lABfXFcdv/13Z5g1udEWVw==; Date: Tue, 25 Jun 2024 16:57:36 +0300 Message-Id: <86jzid9lbj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87frt15dya.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Jun 2024 13:50:21 +0000) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> <87frt15dya.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: monnier@HIDDEN, mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org > Date: Tue, 25 Jun 2024 13:50:21 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > ... So if you could come up with a change to try on > > top of Org 9.6 that would change it back to use overlays for folding, > > we could try that and see if the slowdown goes away, and take it from > > there. > > (setq org-fold-core-style 'overlays) ; before Org is loaded Thanks. Mitchell and Stefan, can you try this? P.S. For some reason, Stefan's email server rejects my mails "due to abuse", I hope it could be fixed soon.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:48:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 09:48:57 2024 Received: from localhost ([127.0.0.1]:36535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sM6XZ-0004WX-KY for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:48:57 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sM6XX-0004WG-AB for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:48:57 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E284C240101 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 15:48:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719323326; bh=L3j5zGMypHOE/0UsXGuk39lOMDDPqhGAwmo1xAtDp5s=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=LKTAqqnjcWTOp8zYMvdGvpBnjaceJh/1zWrcYULWElqSP6sZ2M+xxJclFg7nflKuk ALG2ZeKYwz+wjfG6sq4iCTnyu5ONHePmk1zhdmuDNyBB1MbWVYnGlTIiTn+hqVD98Y NNtAetFoBnioepEWYRb7P/FiMoj0Y/X3lupoFvnNEZQ0w2UUtWbfa3yL0N+AgLHB/p A+3dBmb5yIOAdfTiLbXK0QGce6ZTFU2VFTsGiLb4ORVU585RW5Te4AmPGBkY47hxDn BGDnCYoEBuwVcKQiBUMJWSI7PQteO2nZlgwoq5Izg6wBh8uS3U8cK0EkEfVPDv9VTY 63/yKRlDQsHhQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W7mQ569YDz6twM; Tue, 25 Jun 2024 15:48:45 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <86o77p9lwv.fsf@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> <86o77p9lwv.fsf@HIDDEN> Date: Tue, 25 Jun 2024 13:50:21 +0000 Message-ID: <87frt15dya.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > ... So if you could come up with a change to try on > top of Org 9.6 that would change it back to use overlays for folding, > we could try that and see if the slowdown goes away, and take it from > there. (setq org-fold-core-style 'overlays) ; before Org is loaded -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 13:45:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 09:45:03 2024 Received: from localhost ([127.0.0.1]:36530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sM6Tm-0004Q5-SU for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:45:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sM6Tk-0004PH-CJ for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 09:45:01 -0400 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 <eliz@HIDDEN>) id 1sM6Td-0005sI-33; Tue, 25 Jun 2024 09:44:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hHq+6EHPSj2CvsDG3HWp02ykpAK44tCGasBcBP66Ekw=; b=JPxFqUjyclmA 6J7vq9FGSsC6TbZdg01QkPPriplrj7lj40mXb/Hcjrv5FkS+v6GXbKbJJCCQZzjsCCI9BosvF9pCF hitguLv7eO3QLQwPduTYTVVrbWMRg9aBDWuEV9vb3yeEwMxQvlodEnArBxCN0CInN3AsIuQtefuiO dxKK2fbY46VilUVt6tCs5g3/LNJ/rEk7obm9o/vW/NLWLE3nneP0fkrLhmTmSYMfbFel+GCKE82Dv TP5sman/2Dd76wi+hMQ7IxEvSiF7QJmIUdLnnmNrmh6uCmHBDUzxd/5LD1wAykPqcu84dZm+029AR lSwZtaTQ6xZCQwvm61JMsw==; Date: Tue, 25 Jun 2024 16:44:48 +0300 Message-Id: <86o77p9lwv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87le2t5q07.fsf@localhost> (message from Ihor Radchenko on Tue, 25 Jun 2024 09:30:00 +0000) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> <87le2t5q07.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > 71644 <at> debbugs.gnu.org > Date: Tue, 25 Jun 2024 09:30:00 +0000 > > Stefan Monnier <monnier@HIDDEN> writes: > > > One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the > > version included in Emacs-28.2) the recipe doesn't show the slowdown. > > ... > > If someone more familiar with the changes that occurred in Org around > > that time could try and track down the specific change that triggers the > > problem, that would be appreciated. > > The biggest suspect is the fact that Org switched from overlay-based > folding to text property-based between Org 9.5 and Org 9.6. But overlays aren't supposed to be faster than text properties, so I'm unsure why this change would have such an effect. However, it is important to establish the facts first, and try to explain them later. So if you could come up with a change to try on top of Org 9.6 that would change it back to use overlays for folding, we could try that and see if the slowdown goes away, and take it from there.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 09:28:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 05:28:36 2024 Received: from localhost ([127.0.0.1]:36285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sM2Tc-00033l-9K for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 05:28:36 -0400 Received: from mout02.posteo.de ([185.67.36.66]:49111) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sM2TW-00033O-N6 for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 05:28:34 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D5126240105 for <71644 <at> debbugs.gnu.org>; Tue, 25 Jun 2024 11:28:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719307702; bh=FNN410BJCRIKpK57AcZmk4AGbAs65bj6TxFcoz8I14w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=E42OiyISD4+4tvu5i4rsg6n4BKQxCMspPYkrXJYC5bo9WBb2ZjsamqgeqEZcYRD3z gJSKqS5DIG9uImG7D7uF+Yuli/nOeg7p4LgTy8w7umj8Zt1ffls/YE1tNBpMu5Jj07 yPp3ZNWdwazpPZ9AYqB+olsTFIO7Ds4J7iFMv8BT3VLey1mdX8j2COkNxptvX3QZKS p1uOallGUOczVcLIb/GE08LzncG4942FOrJAeMf8nFmk48/aR3BzTf6XBoooYK8PBt NfliHXlByVMOTb5LeY+mlH87ZHxtaPH9ga8bqOo83bWHNYsRLbOIA6dBJ8ES1V6VBa hzVNuQC/LRoFQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W7fdd027Qz9rxD; Tue, 25 Jun 2024 11:28:20 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> Date: Tue, 25 Jun 2024 09:30:00 +0000 Message-ID: <87le2t5q07.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Stefan Monnier <monnier@HIDDEN> writes: > One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the > version included in Emacs-28.2) the recipe doesn't show the slowdown. > ... > If someone more familiar with the changes that occurred in Org around > that time could try and track down the specific change that triggers the > problem, that would be appreciated. The biggest suspect is the fact that Org switched from overlay-based folding to text property-based between Org 9.5 and Org 9.6. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 04:00:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 25 00:00:59 2024 Received: from localhost ([127.0.0.1]:35967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sLxMY-0000EI-PL for submit <at> debbugs.gnu.org; Tue, 25 Jun 2024 00:00:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sLxMX-0000E7-MD for 71644 <at> debbugs.gnu.org; Tue, 25 Jun 2024 00:00:58 -0400 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 <eliz@HIDDEN>) id 1sLxMP-0005UK-3a; Tue, 25 Jun 2024 00:00:49 -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:In-Reply-To:Subject:To:From: Date; bh=9Tk/8+B9VzNhqDU+/mOHKn0SNSevPCAeuzVa+LOihqU=; b=XTkXobmxNwtQQVYeDaw1 fYRH1nsc72yiQG7CjT7Vikxesics81PKBDWzF4us/lSWOQ7+0oZRboEkDK4558GJ25cbqxthipKfl WQKICOA4ekOX+4isNy1sNZHkQihqC2g0faA8KeWYvBwM/SPh1aacibyeGT3bE8+FKzMISb5kTkUGC AA7nZjJzuSfdTyRmnYlc6pPeK/MRNH/J3rOsnxe7Em4luOoXpwLTq92dfTADchk0I8zmtH5EPmzXF ipA10nrZIb54MFuJ0LG3RSTmjppzSL+jxmCVplFlixSqjq6OULhOzNChWoAz8us/G75hvzL/D6m98 vmdvvUK8AK1CSg==; Date: Tue, 25 Jun 2024 07:00:38 +0300 From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2371644=3A_30=2E0=2E50=3B_Severe_slowdown_in_la?= =?US-ASCII?Q?rger_files_with_markers_beginning_in_emacs_29+?= User-Agent: K-9 Mail for Android In-Reply-To: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> <87wmmhgjao.fsf@localhost> <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN> Message-ID: <71F78866-48D2-4973-91A7-8E9652E49CE7@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Autocrypt: addr=eliz@HIDDEN; keydata= mQENBF+pf4UBCAC6vjkWLSAsQpe8YIGKLQzNOJx/IjGtCdFF8uzmO5jmME+SD8ROuJN+t5KXVw58 uzu75EFD0vHTY9e+udJ2gkpuy0NnzkFcbumdLLo2ERKCoSctZZRhzKXI5z5cHxCqW0B2ygHRrRLt oNlGID7bAgcgSViT1ptGqTXO7zGVu4Airok7dNzcPtHgns8GlR5YAFX0TvE6oGd0l2VPghNeVJKJ OjrbfhoDxl3ucFpqbqMH8z9HTLDOFpz8UaYYUdJMi3xX6vwTZxI2sM2RRVLUpZyllAkSMI4lln1O OgazM/62DJUs/rKIHKBnF6h3/qsJUjUYXaAHbrXY26mWllAd536lABEBAAG0I0VsaSBaYXJldHNr aWkgKGVsaXopIDxlbGl6QGdudS5vcmc+iQE4BBMBAgAiBQJfqX+FAhsDBgsJCAcDAgYVCAIJCgsE FgIDAQIeAQIXgAAKCRCRwSYvAeuNOYUQB/4/iIKKOG45ijNaRoTvmJJZMvj1S07WQxEm7c5SHEeE QbLOAxB9vESOV7sLueuN3oqEndtzyYt4x1WTSBmHFF7h5fcCMjBs41siOIp5Sj/xD0Bvaa0IKGCR SZ7PAo8Mq3wgajXpTpn9vxE2PmtzA8KdEE0K1+f9pVAfOpUIcCl44rIxLUW352XG0y7iz6c/O6LB 1deOKMiKFctKO7pBti1dJEm1ImewLH3H8uTbwspLOs3EB8xhsESxmTidnze68HX2jt+2EeMgCdki NU+LWbexQZPfIS7+ZmE06ll0v6+Jy7ZdTkCCRypKWTnW7pIFsq/p4kybV8O/kHSV6B4vvQBfuQEN BF+pf4UBCACvFrdx/m22lgObypSmSS4TNlNvQnMUorrMmp0U32hv5adt6CKXeMjk05F+GcIfVMrp xqMBn4sEUIXWhhogQJa9ZbWEP/HbS8XjMMbz0Q0Siaty9+DSspK/9u2GWKsz3uQzLCexIJtzmXvj AVmvoMCAU/F2t038ggygjYLRgyLRNLgbbartu2dMkvrfxRjheip60S4S3utOcwUf/qdoa1grNann CFluHr/ftXCeeuGB4H8iO0BXWNby6NZPizxJttx9gdcH8/OmDOJkXyRMTT/3sSem76CSOjfXcz7s aJlg680NQhG5TmuYERjJD4+U02K5RuqTsEnOuWeFy4p+/mslABEBAAGJATYEGAECAAkFAl+pf4UC GwwAIQkQkcEmLwHrjTkWIQTmyQKcNjrUHXh6jruRwSYvAeuNOejsB/9rVegsfEBSRLjeeYXyJrOf dme7BYpYsQCw2vGTnrJTGFQ9HM2zT9+wAENBHWjQPJOptJwo5w4xIbZgwJy0uIN3sV18xbCRSxX0 ZSk8GJG0PrQTCaf2xs0kqsShnkvqyo5QSyUlFUAG7m1o7NUhF95Q89oxGO8JyvR356kqNbzUn0Cq PxKyS42QfC8dyFNgVhVPbZp6aONnUwY5SbtCLJtZCBgvppI9XaBH41BDukSE4GgSLoYsSIGShg4h e+bGypAsGtQ9uwmryUi1gRrDgca3wFo/G0rbJn2ZKoLbGFZivWPVgAgd9/O5sLSPFznOdcRGxEA2 gk7A1ReaJ10PtQz0 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) On June 25, 2024 6:07:32 AM GMT+03:00, Stefan Monnier <monnier@iro=2Eumontr= eal=2Eca> wrote: > One other thing I notice: If I use Emacs-29 but with Org-9=2E5=2E5 (i=2E= e=2E, the > version included in Emacs-28=2E2) the recipe doesn't show the slowdown= =2E >=20 > There's still a good chance that the slow behavior is due to > chars<->bytes conversion (there's no doubt that this code's performance > can be quite poor), but I suspect the reason for the change of behavior > between Emacs-28 and Emacs-29 lies in Org rather than in Emacs's C code= =2E > If someone more familiar with the changes that occurred in Org around > that time could try and track down the specific change that triggers the > problem, that would be appreciated=2E >=20 >=20 > Stefan >=20 >=20 Yes, I think it is very important to find out which changes in Org trigger= ed this issue in Emacs 29=2E
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 03:08:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 24 23:08:56 2024
Received: from localhost ([127.0.0.1]:35914 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sLwYC-00078I-FA
for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:08:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21148)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sLwYA-000783-4C
for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:08:54 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 512AB8053A;
Mon, 24 Jun 2024 23:08:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719284926;
bh=C47KbCiCMgzkJRZ1fGG20MMMJsU5J3bKw8sUbhiEtAw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=ktkfYh6gdZdEJBAilEQw3VoCDr0ewyqXQExzoCZ0hjIKERTt2lXxQWKZtDPa+2krt
vUBeiTdsOCVAaESxxMBYiXzM5Sz+HVTZ7bSj4T9OMiZ47uNsHq7yZEzjYaOdlYsk4t
Ph9Dxq8FZKPzq4QBjJY8Ec6ZKU12OJbFnx08X3BXdiNgMP33DdCkUIArPioPwJPN5m
NkGcZgjITFNgKvkT0d4+cNh2r7aMQ/1nloDOL05KQrm1BCd+rJWyQeQZ9Yqgz7LNuq
5LYKty935OtvbF1km96cYQ31b+SauecKOvh1wCzyEQJSaTDxmxppf4NdMzGLpEfn+G
Y95NlicDCbiMQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 26B65805DE;
Mon, 24 Jun 2024 23:08:46 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EC5B912033B;
Mon, 24 Jun 2024 23:08:45 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <86msnabjnv.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 24 Jun
2024 15:38:12 +0300")
Message-ID: <jwv5xtx2004.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
<86ed8pjwgc.fsf@HIDDEN>
<CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
<86wmmgg7un.fsf@HIDDEN>
<CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
<86msnabjnv.fsf@HIDDEN>
Date: Mon, 24 Jun 2024 23:08:44 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.048 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Maybe someone else could try reverting that change? Stefan, could you
> do that, since you see the regression wrt Emacs 28 on your system?
Removing that patch made no difference in my tests on Emacs-29.
[ And adding it to Emacs-28 also made no difference, in my tests. ]
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 25 Jun 2024 03:07:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 24 23:07:47 2024
Received: from localhost ([127.0.0.1]:35909 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sLwX5-00076S-0S
for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:07:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20675)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sLwX0-000769-HD
for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 23:07:45 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 39CAC10016C;
Mon, 24 Jun 2024 23:07:34 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719284853;
bh=qoSMD/e8SLLYtaKGGfGnV1WzYdl90Rh6hK2rxkC2N+k=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Btwm8XNMOVBlCE4Q6kQFrzUWCpn8biTXIw5gmt1F2Jo9VAE1oRjnNB9r54Z2jYiL2
sip/tqk+Rr7fx8NYawPJTzVt01BCzgi9DkskBvOmBNwhPVGYpSzDhOYuJ5iXo4Qgah
H1AmlNvs+wAdS59Z4o5DqfQEyW/zcrShEQZhgiY5z55CZXT9AIFc4EaQLCjovfMx54
HE4AdZ5ZkyThJIe0crZEqye2wuOdgoev7hTa0Cf24fm/r28fCbINhC47Usto2rMIHo
e33UGc9hpdBX/3K7xLvrLB06e83Wo6yg2WyUg3/2LtkbfDWC7XMEOfDjADsFkTzrp0
oI75/z5Y6ZfjA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 150E2100048;
Mon, 24 Jun 2024 23:07:33 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D47E7120170;
Mon, 24 Jun 2024 23:07:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
Jun 2024 14:10:23 +0000")
Message-ID: <jwvbk3p20ak.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
<87wmmhgjao.fsf@localhost>
Date: Mon, 24 Jun 2024 23:07:32 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.142 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
One other thing I notice: If I use Emacs-29 but with Org-9.5.5 (i.e., the
version included in Emacs-28.2) the recipe doesn't show the slowdown.
There's still a good chance that the slow behavior is due to
chars<->bytes conversion (there's no doubt that this code's performance
can be quite poor), but I suspect the reason for the change of behavior
between Emacs-28 and Emacs-29 lies in Org rather than in Emacs's C code.
If someone more familiar with the changes that occurred in Org around
that time could try and track down the specific change that triggers the
problem, that would be appreciated.
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 24 Jun 2024 12:38:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 24 08:38:23 2024 Received: from localhost ([127.0.0.1]:55758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sLixj-0001fm-8i for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 08:38:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sLixh-0001fH-QP for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 08:38:22 -0400 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 <eliz@HIDDEN>) id 1sLixa-0004qk-2P; Mon, 24 Jun 2024 08:38:15 -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=aRfTJZLv+1aILObIajvJsdadKSrKYmbgrDy7m3ox8uk=; b=ceTlI9OFryrbS9ptq7BE eIGBYu7a6XayozVj1x+7wZ86gs/4mneirfLobJyWyOu4tW9782TWZ+OpcAqIaz+uySIpvlWacb2Hy x4M36jTD2hpQXNamKKTz//YdUbfvm1yPSF3J56xlYfDjvjO0kjNGll2YqJP7vodfASEQN1KJAz443 272FnJ6lceNvV/m4Julbr1GYVSrgkkj7ct+8GhpyRhEPI1wPMc1QQNea9H13Gf/9ExVyAlQOMVGup 6mDHepyjHLFiPa5DW46+m0LQvYgl7C4nwj9WWmVrK9JxHXb6qCtxZMP0GuOdzmwEUCPDsmEE6x3dc RYm7JYhJ3hUVSQ==; Date: Mon, 24 Jun 2024 15:38:12 +0300 Message-Id: <86msnabjnv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: monnier@HIDDEN, Mitchell <mitchellahren@HIDDEN> In-Reply-To: <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN> (message from Mitchell on Mon, 24 Jun 2024 01:09:29 -0600) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> <86ed8pjwgc.fsf@HIDDEN> <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN> <86wmmgg7un.fsf@HIDDEN> <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Mitchell <mitchellahren@HIDDEN> > Date: Mon, 24 Jun 2024 01:09:29 -0600 > Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org > > I am not a programmer by trade. I did previously manage to build the latest version of emacs on Windows as > explained at > https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-from-source-on-windows/ , but > after several hours trying to compile a version of emacs rolled back to just before that commit, I haven’t had > luck. I git-cloned emacs master to my machine, used `git checkout > 8783700b23e70874c4996908bf02c010ae6f3fe1^` to narrow down to the parent of the commit in question, > ran `./autogen.sh` and then `./configure`, and finally tried `make`, but it keeps raising errors. ChatGPT > diagnoses the errors like this: Sorry, I haven't realized you don't have a fully operational build environment for Emacs. The errors you show mean that your development environment is broken. So please forget this. Maybe someone else could try reverting that change? Stefan, could you do that, since you see the regression wrt Emacs 28 on your system?
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 24 Jun 2024 07:11:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 24 03:11:18 2024
Received: from localhost ([127.0.0.1]:43440 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sLdrB-0000wy-Ms
for submit <at> debbugs.gnu.org; Mon, 24 Jun 2024 03:11:18 -0400
Received: from mail-ed1-f50.google.com ([209.85.208.50]:49198)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mitchellahren@HIDDEN>) id 1sLdr8-0000wh-0f
for 71644 <at> debbugs.gnu.org; Mon, 24 Jun 2024 03:11:15 -0400
Received: by mail-ed1-f50.google.com with SMTP id
4fb4d7f45d1cf-57d331cc9feso1920843a12.2
for <71644 <at> debbugs.gnu.org>; Mon, 24 Jun 2024 00:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1719213007; x=1719817807; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=8p2nwWUC5Pl56S26kG3wVnRsAREcVHm63OpBNtR8AbU=;
b=Y0E+JcQLuKp+riiAud0e/7shUVq7ii3GtLswskmOv5JmTP221HH43sE7JJA0A90lev
ZnM4k/nsWKInVxhE6yS0yY85Bho5d5txSfdDUBXiOE9KcgnI2RjIvjCnv61ITW6ZAPk5
WMKU8MAY96R70UFTAIoQf3LCFxL/fGQ57mSpNHq6Oac6H2U4KyGaYb6g173pvfkQc9bY
BigSp2UP5/nRbXcSiC7aoRHge6vPCag6CH6Xwc0k52yelSKaSJ3SvrZJl8i7ttpbgsqi
NwoRhNmApbVwGislavXd4LP1lWPCYlK7YXXL/e9GET+3OBOaMht3cn5Yy3E2Gqgiiy9P
wbFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1719213007; x=1719817807;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=8p2nwWUC5Pl56S26kG3wVnRsAREcVHm63OpBNtR8AbU=;
b=JmWDJIYOhLweAOv2Rv73U3jBW4W46aZ7o1p8DHVwHIYULq1pquaJoqxh5VDezSI+Ip
l126SOj14+VER2+jZCYqvuF0XS//DzXirNN5bhm8B082zDLPj1eLrs2OcYnmnl9Z5owR
EGc5GH65T1xTdbB2Qb2rgVtnPznI3NTn4XcFtjRGNCHVX7lYcStg+iXrelurSH1hb12r
2hIhPemAb8Oot6gVLTODZiGg3Q8/hqV8ZHWqvKye2eyJh6Yu3c2ILDMvlTCFrH05Yogm
CFZ59O3X5xQJkUspnR6yUnXlZh+ndDwRzMsoo7FVz7JixaaCM1W6exqdyT1SEP+J4UJB
LLuw==
X-Forwarded-Encrypted: i=1;
AJvYcCWHEwEx+d8wa/R7GX6H3rxHzjLSjvM50XNp5fu+TSW4AClDQIlHxYgCfiA0EB5PQWcReb5VEoViyh14lLF4sYFtM+szMaI=
X-Gm-Message-State: AOJu0YxhuY0IksuDJYKWi+Eh4pV6nbUgi+CBbsMlkNm/Ns5AitNMDzbI
skv5Fysc5VHF6Pn6CaUuoFi6WmSC1a3DuaqYOKOUB/Sr9upNMDm+diupW3efKh4MDQEjqkrR38D
l0dOtisSevnv9VvCQR76z8z4bMWM=
X-Google-Smtp-Source: AGHT+IGTKAKkNLy6a6Akixhu2h9dy/g5ZLnrTx0xEha9XhrwZGWYAtu4uekaJu1ehmU4mKhuv+ew3gQ4TGHljwFkY4w=
X-Received: by 2002:aa7:d98d:0:b0:57d:6326:c658 with SMTP id
4fb4d7f45d1cf-57d6326cb46mr619601a12.0.1719213006975; Mon, 24 Jun 2024
00:10:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
<86ed8pjwgc.fsf@HIDDEN>
<CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN>
<86wmmgg7un.fsf@HIDDEN>
In-Reply-To: <86wmmgg7un.fsf@HIDDEN>
From: Mitchell <mitchellahren@HIDDEN>
Date: Mon, 24 Jun 2024 01:09:29 -0600
Message-ID: <CAOQwW=YyL9s1k=Mcz7iSaSmCL9wXUrmK-aC+93LCa4f19S0RHw@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers
beginning in emacs 29+
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000092fd60061b9d78f3"
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 71644
Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--00000000000092fd60061b9d78f3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I am not a programmer by trade. I did previously manage to build the latest
version of emacs on Windows as explained at
https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-from-s=
ource-on-windows/
, but after several hours trying to compile a version of emacs rolled back
to just before that commit, I haven=E2=80=99t had luck. I git-cloned emacs =
master
to my machine, used `git checkout 8783700b23e70874c4996908bf02c010ae6f3fe1^=
`
to narrow down to the parent of the commit in question, ran `./autogen.sh`
and then `./configure`, and finally tried `make`, but it keeps raising
errors. ChatGPT diagnoses the errors like this:
Warnings:
calloc Argument Order: Multiple warnings about the incorrect order of
arguments in calloc calls. The first argument should specify the number of
elements, and the second argument should specify the size of each element.
For example:
c
newstate =3D (re_dfastate_t *) calloc(1, sizeof(re_dfastate_t));
These warnings alone should not cause the build to fail but should be
corrected for code correctness and stability.
Errors in sysdep.c:
Implicit Declaration of waitpid:
sysdep.c:472:13: error: implicit declaration of function
'waitpid' [-Wimplicit-function-declaration]
472 | pid =3D waitpid(child, status, options);
This error indicates that waitpid is being used without including the
proper header file that declares it.
Undeclared Identifier WNOHANG:
sysdep.c:518:43: error: 'WNOHANG' undeclared (first use in this
function)
518 | return get_child_status(child, status, WNOHANG | options,
0);
This suggests that WNOHANG is not defined, likely because the appropriate
headers are not included.
Control Reaches End of Non-Void Function:
sysdep.c:519:1: warning: control reaches end of non-void
function [-Wreturn-type]
519 | }
This means the function is expected to return a value but doesn't in
all code paths.
Error in print.c:
Storing the Address of Local Variable:
process.c:7419:53: error: storing the address of local variable
'buf' in 'current_thread->stack_top' [-Wdangling-pointer=3D]
This indicates a potential issue with a dangling pointer, where the address
of a local variable is being assigned to a global or long-lived structure.
If you have any advice I=E2=80=99m happy to try compiling it again. Or perh=
aps Ihor
or Stefan would have more luck rolling back emacs to just before that
commit to confirm that=E2=80=99s the issue? Sorry!
--00000000000092fd60061b9d78f3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I am not a programmer by trade. I did previously mana=
ge to build the latest version of emacs on Windows as explained at <a href=
=3D"https://readingworldmagazine.com/emacs/2022-02-24-compiling-emacs-29-fr=
om-source-on-windows/">https://readingworldmagazine.com/emacs/2022-02-24-co=
mpiling-emacs-29-from-source-on-windows/</a> , but after several hours tryi=
ng to compile a version of emacs rolled back to just before that commit, I =
haven=E2=80=99t had luck. I git-cloned emacs master to my machine, used `<c=
ode class=3D"gmail-!whitespace-pre gmail-hljs gmail-language-sh">git checko=
ut 8783700b23e70874c4996908bf02c010ae6f3fe1^</code>` to narrow down to the =
parent of the commit in question, ran `./autogen.sh` and then `./configure`=
, and finally tried `make`, but it keeps raising errors. ChatGPT diagnoses =
the errors like this: <br></div><div><br></div><div>Warnings:<br>=C2=A0 =C2=
=A0 calloc Argument Order: Multiple warnings about the incorrect order of a=
rguments in calloc calls. The first argument should specify the number of e=
lements, and the second argument should specify the size of each element. F=
or example:<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 c<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0=C2=A0 =C2=A0 newstate =3D (re_dfastate_t *) calloc(1, sizeof(=
re_dfastate_t));<br>=C2=A0 =C2=A0 These warnings alone should not cause the=
build to fail but should be corrected for code correctness and stability.<=
br>Errors in sysdep.c:<br>=C2=A0 =C2=A0 Implicit Declaration of waitpid:<br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s=
ysdep.c:472:13: error: implicit declaration of function 'waitpid' [=
-Wimplicit-function-declaration]<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 472 | pid =3D waitpid(child, status, options);<=
br>This error indicates that waitpid is being used without including the pr=
oper header file that declares it.<br>Undeclared Identifier WNOHANG:<br>=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 sysdep.c:518:43: =
error: 'WNOHANG' undeclared (first use in this function)<br>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 518 | return get_chi=
ld_status(child, status, WNOHANG | options, 0);<br>This suggests that WNOHA=
NG is not defined, likely because the appropriate headers are not included.=
<br>Control Reaches End of Non-Void Function:<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0=C2=A0 =C2=A0 sysdep.c:519:1: warning: control reaches end of non-void f=
unction [-Wreturn-type]<br>=C2=A0 =C2=A0 519 | }<br>=C2=A0 =C2=A0 This mean=
s the function is expected to return a value but doesn't in all code pa=
ths.<br>Error in print.c:<br>=C2=A0 =C2=A0 Storing the Address of Local Var=
iable:<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 process.c:7419:53: err=
or: storing the address of local variable 'buf' in 'current_thr=
ead->stack_top' [-Wdangling-pointer=3D]<br>This indicates a potentia=
l issue with a dangling pointer, where the address of a local variable is b=
eing assigned to a global or long-lived structure.</div><div><br></div><div=
>If you have any advice I=E2=80=99m happy to try compiling it again. Or per=
haps Ihor or Stefan would have more luck rolling back emacs to just before =
that commit to confirm that=E2=80=99s the issue? Sorry!<br></div></div>
--00000000000092fd60061b9d78f3--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 18:17:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 14:17:46 2024 Received: from localhost ([127.0.0.1]:55381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sL5J4-0007Gb-Cy for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:17:46 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sL5J2-0007GN-AB for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:17:44 -0400 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 <eliz@HIDDEN>) id 1sL5Iw-000299-S6; Sat, 22 Jun 2024 14:17:38 -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=zyqRqHqywKk9x2n1qcTUtLefRiYgAdhsul7bpXdXR8o=; b=eH66Q80NKkfA/u9wHBBK GbJADyy188Ac1ZuxwkZH6KLJgyI8cZm2j7CXjKQF+WfqT2ja54DwIVx6UjvvuSmkEHjJTkaqpzn8n xo8YCSE0WA44nopSztaaedtucdAtRVFlxuOe7beYZ+sASemqEUNAZZtoMbSIp/RCXgHIHikMCfJoH vvoGRBObzqTZmJCNZdeUq24h+gPUt2z47TlyJFIu0N1crwYE0bC1YY42peQ4hxHlOF8fHZbHC19KP IMrj1S2wztiqhy8dOmS3xayH3alTqknmkhOVv0WxuHBo0/lqZuaLjEJQATAPB3cvknhMGv5DAB3m/ pXuERQ+hwRqXbQ==; Date: Sat, 22 Jun 2024 21:17:36 +0300 Message-Id: <86wmmgg7un.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Mitchell <mitchellahren@HIDDEN> In-Reply-To: <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN> (message from Mitchell on Sat, 22 Jun 2024 12:03:05 -0600) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> <86ed8pjwgc.fsf@HIDDEN> <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: monnier@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Mitchell <mitchellahren@HIDDEN> > Date: Sat, 22 Jun 2024 12:03:05 -0600 > Cc: Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org > > On Sat, Jun 22, 2024 at 12:58 AM Eli Zaretskii <eliz@HIDDEN> wrote: > > > > From: Stefan Monnier <monnier@HIDDEN> > > > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org > > > Date: Fri, 21 Jun 2024 17:06:31 -0400 > > > > > > > commit 8783700b23e70874c4996908bf02c010ae6f3fe1 > > > > Author: Stefan Monnier <monnier@HIDDEN> > > > > AuthorDate: Tue Aug 2 10:38:53 2022 -0400 > > > > Commit: Stefan Monnier <monnier@HIDDEN> > > > > CommitDate: Tue Aug 2 13:06:51 2022 -0400 > > > > > > > > * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1 > > > > > > > > It changed the comparison operator in two places in marker.c. > > > > > > > > Curiously, the log message doesn't even mention the change in > > > > marker.c, which could be a sign that this change was not intended to > > > > be installed. Stefan, did you intend to install it, and if so, do you > > > > have any comments about this bug report? > > > > > > Hmm... can't remember why/how it ended up in the above commit. > > > Looks like an oversight. But the change should be harmless: the > > > `eassert` should make sure that the comparison gives the same answer > > > either way (and AFAICT if/when the new comparison gives a different > > > answer from the old code, the old code will loop until it segfaults). > > > > Mitchell, can you try reverting that change, and see if that affects > > performance in your case? > > Eli, after Ihor and Stefan were able to reproduce it now, would it still be helpful for me to do this and report > back? I’m more than happy to if it would help in any way. Yes, because we still don't understand well why performance regressed from Emacs 28 to Emacs 29. > Also should I be replying to the renamed thread from now on? (i.e., "chars==bytes (was: bug#71644: 30.0.50; > Severe slowdown in larger files with markers beginning in emacs 29+") This is my first bug report, so I’m not > sure the etiquette, haha. No, please keep replying with the original Subject. That other thread was a side issue.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 18:04:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 14:04:51 2024 Received: from localhost ([127.0.0.1]:54946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sL56Y-0006oj-Lx for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:04:51 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:50687) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mitchellahren@HIDDEN>) id 1sL56W-0006oM-L8 for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 14:04:49 -0400 Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-57cb9a370ddso3408778a12.1 for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 11:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719079423; x=1719684223; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=su6aDWKFkbQ8+hu0mQki+XFaWw+x3OMrKWBvARUph0E=; b=Bhoays4B6HZupUdsrkfWjPvcF+WmrpF6urmW8RILAur3i7tqOHU27djF17ZOOWDRzC I02UWr+yYexrw+y5Q+P7EdVsDXvF6eqjXQvayeI5+fmzP56fgSjS7c4DkZANCSGlrIk+ d6i1YJ6YBKBtysm9vTKKPX5wwp50Y/AtiHGN+4AEZzOIOasVmBBwJkpK5dzyXSrzqcqG fraOxcXe2f3JQOsEjQAYhTCavRM5d/W4AiQ/WPrVOxKWahA4VwtAaIkLJYLGPrztQWv4 um+KDR/MCe92qtN5x46r8c1lvR41JKGyXJbzfKgVvhyc+DAi0Jm6Vtd9UfeVdZ1qAv5E ihrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719079423; x=1719684223; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=su6aDWKFkbQ8+hu0mQki+XFaWw+x3OMrKWBvARUph0E=; b=s7+mU4HoePgziln+cqtJsT/Gma8qCsLaIIAG4H8uwXzfJgkccdmH0n5R+7wnf/tQFU ztVp7X6K/hWcbn9gKnMo/Hjpgdckm1mOaZnZFM0R1Rvc9R/S7x2CnTnNE8DutWmGdE2Z n+c9/5sDS6tQ3rbXwUC6/69hJYK157HUxUM6LUS0tPY48XMpMihY8OPDCB5grDtvXO0v CbcWK6soYjAN9Vp8WBeB1bNm2/fcJbnhq3Y4zUTsIzSiojoaHkrAfTeTqS9s+IjT7M5o i6F1buW1cUCRenCrb4s1G69bZo1I0U0tJaBdMY5H6JA7PhhC2hos1YGPIHtj27vvdhHe eDmw== X-Forwarded-Encrypted: i=1; AJvYcCWq7dZg4p683su2NLiuJarXFl4MST48AN6LMAQWZAe+eJ7cZN4mLwqXDstMQ+rDAko5bEyJA3H0K+c7uaQZ2JQfXZYdq/s= X-Gm-Message-State: AOJu0Ywl2gfreP0VgN4jrFbRx8Il8ve2y1AqrjXHTDOxJh8h/lCf9aYN vwQdTIAKLwhf6Y1z39L8hu2SeRLaRTpnGiQI5obkDR9nnPHtjOsY9YszsegShE9bfFyC1GX7l6q JIA0fdz/fd+QcgYbQd/twDU9BF/o= X-Google-Smtp-Source: AGHT+IF2OHdHNTh2KkH7ti1SD+yR80Zp0IUlRCxYJGdHjf2ozpPWtJMP+jT4/c7mjJ+8sRmsTPSG4DnI+ZJ9sZOAbN0= X-Received: by 2002:a50:c04f:0:b0:57d:3791:e8e4 with SMTP id 4fb4d7f45d1cf-57d4bdcad8dmr345923a12.32.1719079422529; Sat, 22 Jun 2024 11:03:42 -0700 (PDT) MIME-Version: 1.0 References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> <86ed8pjwgc.fsf@HIDDEN> In-Reply-To: <86ed8pjwgc.fsf@HIDDEN> From: Mitchell <mitchellahren@HIDDEN> Date: Sat, 22 Jun 2024 12:03:05 -0600 Message-ID: <CAOQwW=brAYFVGjngvxnrKQ+_nSO_04BBXEpYWKpBOPYV0Zj0+w@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000052192f061b7e5e3b" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71644 Cc: Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --00000000000052192f061b7e5e3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 22, 2024 at 12:58=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote= : > > > From: Stefan Monnier <monnier@HIDDEN> > > > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org > > > Date: Fri, 21 Jun 2024 17:06:31 -0400 > > > > > > > commit 8783700b23e70874c4996908bf02c010ae6f3fe1 > > > > Author: Stefan Monnier <monnier@HIDDEN> > > > > AuthorDate: Tue Aug 2 10:38:53 2022 -0400 > > > > Commit: Stefan Monnier <monnier@HIDDEN> > > > > CommitDate: Tue Aug 2 13:06:51 2022 -0400 > > > > > > > > * src/xdisp.c (redisplay_window): Use BEG rather than hard > coding 1 > > > > > > > > It changed the comparison operator in two places in marker.c. > > > > > > > > Curiously, the log message doesn't even mention the change in > > > > marker.c, which could be a sign that this change was not intended t= o > > > > be installed. Stefan, did you intend to install it, and if so, do > you > > > > have any comments about this bug report? > > > > > > Hmm... can't remember why/how it ended up in the above commit. > > > Looks like an oversight. But the change should be harmless: the > > > `eassert` should make sure that the comparison gives the same answer > > > either way (and AFAICT if/when the new comparison gives a different > > > answer from the old code, the old code will loop until it segfaults). > > > > Mitchell, can you try reverting that change, and see if that affects > > performance in your case? > Eli, after Ihor and Stefan were able to reproduce it now, would it still be helpful for me to do this and report back? I=E2=80=99m more than happy to i= f it would help in any way. Also should I be replying to the renamed thread from now on? (i.e., "chars=3D=3Dbytes (was: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+") This is my first bug report, so I=E2= =80=99m not sure the etiquette, haha. --00000000000052192f061b7e5e3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Sat, Jun 22, 2024 at 12:58=E2=80=AFAM Eli Zaretskii <<a href= =3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>> wrote:<br><= /div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo= rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div> >=20 > From: Stefan Monnier <<a href=3D"mailto:monnier@HIDDEN" t= arget=3D"_blank">monnier@HIDDEN</a>><br> >=20 > Cc: Mitchell <<a href=3D"mailto:mitchellahren@HIDDEN" target=3D"= _blank">mitchellahren@HIDDEN</a>>,=C2=A0 <a href=3D"mailto:71644@debb= ugs.gnu.org" target=3D"_blank">71644 <at> debbugs.gnu.org</a><br> >=20 > Date: Fri, 21 Jun 2024 17:06:31 -0400<br> >=20 > <br> >=20 > >=C2=A0 =C2=A0commit 8783700b23e70874c4996908bf02c010ae6f3fe1<br> >=20 > >=C2=A0 =C2=A0Author:=C2=A0 =C2=A0 =C2=A0Stefan Monnier <<a href= =3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN= l.ca</a>><br> >=20 > >=C2=A0 =C2=A0AuthorDate: Tue Aug 2 10:38:53 2022 -0400<br> >=20 > >=C2=A0 =C2=A0Commit:=C2=A0 =C2=A0 =C2=A0Stefan Monnier <<a href= =3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN= l.ca</a>><br> >=20 > >=C2=A0 =C2=A0CommitDate: Tue Aug 2 13:06:51 2022 -0400<br> >=20 > ><br> >=20 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0* src/xdisp.c (redisplay_window): Use B= EG rather than hard coding 1<br> >=20 > ><br> >=20 > > It changed the comparison operator in two places in marker.c.<br> >=20 > ><br> >=20 > > Curiously, the log message doesn't even mention the change in= <br> >=20 > > marker.c, which could be a sign that this change was not intended= to<br> >=20 > > be installed.=C2=A0 Stefan, did you intend to install it, and if = so, do you<br> >=20 > > have any comments about this bug report?<br> >=20 > <br> >=20 > Hmm... can't remember why/how it ended up in the above commit.<br> >=20 > Looks like an oversight.=C2=A0 But the change should be harmless: the<= br> >=20 > `eassert` should make sure that the comparison gives the same answer<b= r> >=20 > either way (and AFAICT if/when the new comparison gives a different<br= > >=20 > answer from the old code, the old code will loop until it segfaults).<= br> >=20 <br> >=20 Mitchell, can you try reverting that change, and see if that affects<br> >=20 performance in your case?<br></div></blockquote><div><br> </div><div>Eli, after Ihor and Stefan were able to reproduce it now, would = it still be helpful for me to do this and report back? I=E2=80=99m more than happy = to=20 if it would help in any way. <br></div><div><br></div><div>Also should I be= replying to the renamed thread from now on? (i.e., "chars=3D=3Dbytes = (was: bug#71644: 30.0.50; Severe slowdown in larger files with markers begi= nning in emacs 29+") This is my first bug report, so I=E2=80=99m not s= ure the etiquette, haha.<br></div><div>=C2=A0</div></div></div> --00000000000052192f061b7e5e3b--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 15:52:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 11:52:25 2024
Received: from localhost ([127.0.0.1]:50501 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sL32O-00020v-Mb
for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:52:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25732)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sL32N-00020Z-0C
for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:52:23 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9B57044212F;
Sat, 22 Jun 2024 11:52:15 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719071529;
bh=kbWq6dpFJMeDg6qGg+/mtp3lRgzdIGAsP5qKqA0T8x4=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=WDZTMO4tqDHkA7ONe4BPB5v0jfrNAumjvs+wu58Gxv59jWjMKjbQAvyCpzS/mTun0
lTmLro3jTZmxAaFMVXQ27wG546KTFe1zKbXxKzovLZexnjTNU05J3uPF+8gBowwNnw
3GBiUbMwLqA3eB72Vq5NhF5aq9Zyf69RynLBjIcnSPyTAjhkkoeTscYCia8KUayWjv
EmYWOAlAdsbgrkx9T/K5WA5Reaot+m1tWsJJXGui6d2CCyl5/VthGv8TopSDuLVlOO
V2/jPYM5lB8Pca2786/lL48TZMqdA0kvVAe5nM3XOGRMPMxi47Ri8u4ghtLmYNsGNZ
BmIsvvWFxVpLA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5866D4420EF;
Sat, 22 Jun 2024 11:52:09 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 23F45120828;
Sat, 22 Jun 2024 11:52:09 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <87wmmhgjao.fsf@localhost> (Ihor Radchenko's message of "Sat, 22
Jun 2024 14:10:23 +0000")
Message-ID: <jwvbk3t6lu4.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
<87wmmhgjao.fsf@localhost>
Date: Sat, 22 Jun 2024 11:52:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.113 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> (BTW, we should probably merge this bug and bug#63040 where I first
> shared this patch - just to demonstrate the problem and discuss possible
> solutions)
Ah, thanks, I'll take a look at that bug.
> Another idea could be moving the cache markers into a separate
> array, so that we can examine them without mixing with all other
> buffer markers.
=F0=9F=99=82
>> Using markers as a cheap cache of conversions was a cute hack but we
>> really need to replace it.
>>
>> Some options that come to mind:
>>
>> - Keep the tradition of abusing an existing data structure, and stash
>> the bytepos info inside the overlay tree or the text properties.
>> This way the conversion is bounded by O(log BUFFERSIZE).
>
> For overlay tree, it might be even better to stash all the markers in
> Emacs into itree structure.
Yes, I don't really distinguish the itree structure and the overlay
tree, but indeed we could have a separate itree for the markers.
> For now, every operation involving
> adjusting/searching markers scales linearly - not ideal.
Adjusting only happens upon insertion, and while it's definitely not
ideal, it's surprising how little it bites in practice.
And if we move to an array-with-gap it'll bite even much less.
As for searching markers, AFAIK the only time we do that is for ....
.... the bytes<->chars conversion =F0=9F=99=82
[ Admittedly, we also do a search when we delete a marker, but that'd be
easy to optimize away in the common case if we cared about it. ]
IIRC, XEmacs doesn't use a linked-list of markers but an array-with-gap
of markers instead. Not sure if they keep it sorted, but if they do, such
an array-with-gap can even be binary-searched, so it's quite efficient.
>> - Use a dedicated data-structure. E.g. a pair of array-with-a-gap
>> (one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
>> STEP would be a large enough constant to make those arrays cheap yet
>> small enough that the remaining scan is cheap).
>> This way the conversion is O(STEP), i.e. "constant-time".
> I think that it will be less efficient compared to using a tree-like
> structure (if we can manage to use it). Will it be easier?
Given we've survived with a *really* poor data-structure until now,
I suspect that we don't need to worry about choosing the most efficient
option. =F0=9F=99=82
>> BTW, among my various local hacks, I've been using the hack below, which
>> aims to randomize the order in our markers-list, so as to minimize the
>> risk that we have to wade through lots of markers all clumped around the
>> same position. I don't think it does a good job of it, but maybe we can
>> improve the execution of this idea, tho it still doesn't help if there's
>> no GC involved.
> I am not sure if I believe that this approach can yield practical gains.
Neither am I. Another idea I had in the same vicinity (and hence
arguably just as unconvincing) was that in buf_*pos_to_*pos, when we
exit the
for (tail =3D BUF_MARKERS (b); tail; tail =3D tail->next)
loop, we could move the markers we just skipped to the end of the list,
based on the idea that we've just found them to be useless at the head.
Doing it efficiently requires keeping a pointer to the end of the list, tho.
> AFAIU, the problem with the slowdown we are discussing here is markers
> that are all around the same position. It's rather too many markers in
> general, spaced not far from each other.
Sounds about right. But if we could keep them nicely randomized (which
was my original goal with my quick hack), then the total number of
markers wouldn't matter that much because the first N markers in the
list would still be (probabilistically) nicely spread over the
whole buffer.
>> BTW, if/when we use some other data-structure to convert bytes<->chars,
>> then we could presumably get rid of our markers-list and stash markers
>> inside our overlay tree (basically represent them as degenerate overlays
>> with beg=3D=3Dend and no properties).
> I am wondering why it is impossible to stash markers inside overlay tree
> without doing anything special about bytes<->chars conversion (other
> than changing the linear loop with itree query).
I think the answer is that it's not not possible.
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 15:09:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 11:09:39 2024
Received: from localhost ([127.0.0.1]:49250 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sL2N0-0000K7-Bh
for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:09:39 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6582)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sL2My-0000Jl-3Q
for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 11:09:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 92DB044418E;
Sat, 22 Jun 2024 11:09:28 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719068966;
bh=mzaljtl/ikyK/fIuitP1Hqoy+cyA7gBxNYHTf2bGS7I=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=VtYvXBvvLtxUxyB59TFqhptVJD9U+mYLz4SqmbrE2cRLSRgZoYmeG5PcfDwt/jWE4
ZPmFxNJ6/BDrPGGm1dnsmJp+R5rFMN2pu570LB8wU4eCEoOwQQnkCaPJ93/niDbO4h
0O5ApGMdQ3MW4RhIbYkk4V5iABEa+xgMeZVC4fGgYfRkfwC2+Ffrqfe3no8rCeX3hN
mBmDdb7YSImONGum5QFDvnCMZeJULqpCWw6H0UaH2tGz1h2ug+nng8okO+9TmQFhou
UFBcMfH31JHc1WvPkAhn/Wtc0DON4oLyzA14Qcmo7rNcAj4ZUwBjHFHeSZm5rTaBZV
nzeJ8EbnlFAYw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A46EA442179;
Sat, 22 Jun 2024 11:09:26 -0400 (EDT)
Received: from pastel (unknown [24.140.236.196])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 78A8F12022C;
Sat, 22 Jun 2024 11:09:26 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Mitchell <mitchellahren@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
(Mitchell's message of "Tue, 18 Jun 2024 23:25:18 -0600")
Message-ID: <jwvmsnd6o75.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
Date: Sat, 22 Jun 2024 11:09:25 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.115 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> 1. Start emacs 29.3 (or 30.0.50) with emacs -q.
> 2. Paste the minimal config at
> https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de into the
> scratch buffer and eval-buffer. (Note on my system I'm using the `counsel`
> version current as of counsel-20240502.743, but any recent version will
> reproduce the bug).
I used the code below:
(customize-set-variable 'large-file-warning-threshold nil)
(package-install 'counsel)
(package-activate 'counsel)
> 7. Start typing `n` `space`, or `t` `space` several times very fast and
> observe how long it takes for the abbrev expansions (defined in the minim=
al
> config above) to show up on the screen.
Without running `counsel-outline`, the insertion is "immediate", whereas
after `counsel-outline` it takes about two seconds for me.
> Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and 5,
> and then `profiler-stop` after Step 7, I get a very big entry (e.g., 70%)
> for `redisplay_internal (C function)` in the `profiler-report`. Using the
> `profiler` at the same points using emacs 28.2, I don=E2=80=99t get a big=
entry for
> `redisplay_internal (C function)`.
[ I haven't been able to get a meaningful profiler report yet.
E.g. I get 82% of the time given to `read-from-minibuffer`, which is
presumably the time spent typing `M-x profiler-report RET` or some
such, even though I typed enough `n SPC` repetitions that it should
dwarf that. Not sure what's going on. ]
Also I notice that if I do `n` and then wait, it takes the same
amount of time to see the result as if I do `n n n n`
and then wait. So it seems that the command themselves execute
"instantly", and the delay occurs later (jit-lock? redisplay? ...).
I also notice that step 6 is important: if I just go straight to line 35
and type text, there's no delay.
Other thing I noticed
M-g M-g 60000 RET
n n n n n
M-g M-g 35 RET
n n n n n
there's no delays typing the `n` at line 60000 but there is a 2s delay
at line 35.
The fact that the absence of non-ASCII chars eliminates the problem
strongly points the finger to the bytes<->chars conversion which relies
on markers, indeed, but it's still very puzzling: line 35 is about 1.5kB
from the beginning of the buffer, so the conversion should be simple
and fast. there. IOW, if it's a slow bytes<->chars conversion it's
probably a conversion taking place elsewhere than near point.
AFAICT the most significant change w.r.t markers in Emacs-29 is that
markers aren't used internally for overlays any more, so there are
usually *fewer* markers in Emacs-29 buffers than in Emacs-28 buffers
(which can be both favorable and detrimental to bytes<->chars
conversion, depending on details). But in any case, (overlays-in
(point-min) (point-max)) tells me there's only one overlay and even 0 in
Emacs-28, so that can't be the reason for the change.
Stefan "puzzled"
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:15:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 10:15:59 2024 Received: from localhost ([127.0.0.1]:47482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sL1X5-0006uC-Dn for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:15:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51940) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sL1X3-0006tn-Kx for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:15:58 -0400 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 <eliz@HIDDEN>) id 1sL1Wv-0006HL-Fg; Sat, 22 Jun 2024 10:15:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=PN9MRAFHiY25yVlwNGaCNJKItmJBwcFAav0ByvP94hc=; b=lIFhdvhebOeP OlQE3Gsv7iesWy8rYSBG6Xpl/D3j/aBds0xOQBDitK23+wD83bXrEsGEVMFn+WoA8wmjgNc003kLU PRYzTYIZrx/Ma+40UiE9kfecKLzFtSTJ/Jttpk95q2ohCQFsMilLXRa9ChyvP2D7fRbk4uBkixeBO xWE8f1gwjAmfz/EB/I8txtRILzbtZ/v2QayQyaGpOIJxIxE2C4tk3LnXZWZgzjW+5a3rMv/I0fksw V+zi8v1Ean8+HVuxEuidqpE+Dg/gBTMKswdKJukTaxBvETwlmU33f86ILzZxngmBcPEeIiXifVdcz h05iMN6DY45j4Dkn6y3zWA==; Date: Sat, 22 Jun 2024 17:15:46 +0300 Message-Id: <86h6dlgj1p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: yantar92@HIDDEN, mitchellahren@HIDDEN In-Reply-To: <86iky1gj6o.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 22 Jun 2024 17:12:47 +0300) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <87zfrdgk3f.fsf@localhost> <86iky1gj6o.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org > Date: Sat, 22 Jun 2024 17:12:47 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > Not the markers, but conversion of character positions to buffer > positions. ^^^^^^ ^^^^^^^^^ Sorry, I meant byte positions, of course.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:13:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 10:13:01 2024 Received: from localhost ([127.0.0.1]:47362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sL1UC-0006nK-So for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:13:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sL1UA-0006my-4F for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:12:59 -0400 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 <eliz@HIDDEN>) id 1sL1U4-0005M8-4V; Sat, 22 Jun 2024 10:12:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mmU3Hqlq3zYUZenhbQ8yjLn/cpy9S2tFJRXPQ6Wk14Y=; b=g3W7SNUh9zQ/ 6q/oXO2LvdGoNwv0NlNDkfOzMiS8x2CfVnIOVGLzQPB2qUPr7sXLEUaCK7lgEcAemLjeHKk8HB+h0 rTv1ENxEV63vTo5myLvX2uqsW1RgoB2wA0leNSFKsIcqTZmR7xkrwYM60haiLaYxTH89KtvI7ZZ7o rzG7Y0pjOw8ZDmU4a/mviB4yGa/PyZtv5LtdXEF6FEvRkblPgi4cyZaHSyXfRlhpixzwiq/j7b1Qn 9mc36v860U5+kAheu7858ThOUYcpukpkTIpkZKTOGdJUAF+fs+AGB2bxk4NLEuF1oSeBd2YlF4DIX XQnQDnKZwUgDe8ZmnvK25Q==; Date: Sat, 22 Jun 2024 17:12:47 +0300 Message-Id: <86iky1gj6o.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87zfrdgk3f.fsf@localhost> (message from Ihor Radchenko on Sat, 22 Jun 2024 13:53:08 +0000) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <87zfrdgk3f.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 71644 <at> debbugs.gnu.org > From: Ihor Radchenko <yantar92@HIDDEN> > Date: Sat, 22 Jun 2024 13:53:08 +0000 > > Mitchell <mitchellahren@HIDDEN> writes: > > > Here are the steps to reproduce the issue: > > ... > > For the record, I am able to reproduce the problem using the latest > Emacs master. > > And the problem does disappear with my patch that affects the marker > loop in src/marker.c (buf_bytepos_to_charpos) > > So, markers appear to be the culprit on my system. Not the markers, but conversion of character positions to buffer positions. Which uses markers, but that's an implementation detail...
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 14:08:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 10:08:49 2024
Received: from localhost ([127.0.0.1]:47232 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sL1Q8-0006f3-VF
for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:08:49 -0400
Received: from mout02.posteo.de ([185.67.36.66]:49711)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1sL1Q6-0006el-Jd
for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 10:08:47 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout02.posteo.de (Postfix) with ESMTPS id C00AF240103
for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 16:08:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1719065320; bh=NEYDy0q8Al0jhoD5qSbKSfnt4hRb/+sUDIOO8tlMKhU=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
From;
b=ikyN5m5WUUg2qMmUNSXy3Gb3ElY2daBB2DEsktxM+ZeP41f86JzxMI9vl466GTXjX
/VVREveM6bcR8WIfhH1tImbzy3htNt2YNrrqF2T7d5WNrjcyoYEjoel5mXXQxWb9pu
2zLXALYGLa0d0jIyL+jZ+ljokXyJoLf12IzD72we1LMm84Y7l8sjL9m43nmfSgQD5y
FTiNeDQ9fHvCCBka6xWUwOz7W74ituXbd+xdo51oT8FjNA0qC3B2PCHvCmR786k3+C
MdCW6et53ra7vt7f0b2ITsx27U2TDLDlpIfsQLOSxWL7zc+TnRLtwSeXTJy+W+Qik8
1eBgZ2Ih5ggCA==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4W5x0S07LJz6tyX;
Sat, 22 Jun 2024 16:08:39 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
Date: Sat, 22 Jun 2024 14:10:23 +0000
Message-ID: <87wmmhgjao.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Stefan Monnier <monnier@HIDDEN> writes:
>> I got 5x `re-search-forward' speed improvement in my setup with this
>> dumb change.
>
> Hmm... of course, there'd likely be other circumstances where it would
> make it 5x slower. E.g. in a large buffer, doing a forward search from
> the middle of the buffer when the first 50 markers happen to all be near
> the beginning of the buffer will mean that we always use the "slow path"
> which scans all the bytes between PT and the position of interest to
> count the number of chars therein.
Yup. I _do not_ propose my patch to be merged.
(BTW, we should probably merge this bug and bug#63040 where I first
shared this patch - just to demonstrate the problem and discuss possible
solutions)
> BTW, we already stop after at most N/50 markers where N is the smallest
> distance between the position of interest and point/bob/eob/gap (oh and
> the position of the last conversion). So it seems that in your test,
> this distance N is >2500. Also when that distance is >5000 we create
> a new marker, so next time around that position should be at the
> beginning of the marker-list. So I wonder what happens in your test:
> why do we jump "very far" (more than 2500) between each call to the
> conversion function? Also, maybe we should increase
> BYTECHAR_DISTANCE_INCREMENT? ]
It is indeed another option.
Also, from bug#63040
Another idea could be moving the cache markers into a separate
array, so that we can examine them without mixing with all other
buffer markers.
> Using markers as a cheap cache of conversions was a cute hack but we
> really need to replace it.
>
> Some options that come to mind:
>
> - Keep the tradition of abusing an existing data structure, and stash
> the bytepos info inside the overlay tree or the text properties.
> This way the conversion is bounded by O(log BUFFERSIZE).
For overlay tree, it might be even better to stash all the markers in
Emacs into itree structure. For now, every operation involving
adjusting/searching markers scales linearly - not ideal.
> - Use a dedicated data-structure. E.g. a pair of array-with-a-gap
> (one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
> STEP would be a large enough constant to make those arrays cheap yet
> small enough that the remaining scan is cheap).
> This way the conversion is O(STEP), i.e. "constant-time".
I think that it will be less efficient compared to using a tree-like
structure (if we can manage to use it). Will it be easier?
> BTW, among my various local hacks, I've been using the hack below, which
> aims to randomize the order in our markers-list, so as to minimize the
> risk that we have to wade through lots of markers all clumped around the
> same position. I don't think it does a good job of it, but maybe we can
> improve the execution of this idea, tho it still doesn't help if there's
> no GC involved.
I am not sure if I believe that this approach can yield practical gains.
AFAIU, the problem with the slowdown we are discussing here is markers
that are all around the same position. It's rather too many markers in
general, spaced not far from each other.
> BTW, if/when we use some other data-structure to convert bytes<->chars,
> then we could presumably get rid of our markers-list and stash markers
> inside our overlay tree (basically represent them as degenerate overlays
> with beg==end and no properties).
I am wondering why it is impossible to stash markers inside overlay tree
without doing anything special about bytes<->chars conversion (other
than changing the linear loop with itree query).
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 13:51:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 09:51:36 2024 Received: from localhost ([127.0.0.1]:44729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sL19T-0005dX-RL for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 09:51:36 -0400 Received: from mout01.posteo.de ([185.67.36.65]:39069) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sL19Q-0005dJ-TP for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 09:51:34 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A6363240028 for <71644 <at> debbugs.gnu.org>; Sat, 22 Jun 2024 15:51:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719064286; bh=erPcSXhgVcXCneKH2EUCq/sjaHsU6I/cLv3uUf4Kkfo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=pWgEb7XG2zNqFmxNQ24eWhdDS3B6GGs2TDkxZpKWS+9MHz3fEoDeiS19fCd63KOLW l4U2TvjKCNbd/ONmUCeW6Yv4Pwnpx6P7IlQuEqnxJJeoLImRN2Fly8NC6Z+74Tmx0I nX6nGwG/Gwjb5E4rM1JqNqYseu7DY//aaGRONoGhBPYC2PT2Ejs7/Z/wyHGrFb+w/y EKkOY1qNBfml2hiX69F7gLiLen3kxznpPvEtW3jKsvWBbcRyMxw54406CkA1m/dPs+ FuSiZ4ZQGNS39vxLD5OaAMEgJX2F3nIwpO5wCflWbXMVxwOtnt9az8ca9hgQQbbwdN 0C6sVxFb4VZjQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W5wcY1PyQz9rxD; Sat, 22 Jun 2024 15:51:25 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Mitchell <mitchellahren@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> Date: Sat, 22 Jun 2024 13:53:08 +0000 Message-ID: <87zfrdgk3f.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Mitchell <mitchellahren@HIDDEN> writes: > Here are the steps to reproduce the issue: > ... For the record, I am able to reproduce the problem using the latest Emacs master. And the problem does disappear with my patch that affects the marker loop in src/marker.c (buf_bytepos_to_charpos) So, markers appear to be the culprit on my system. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 06:58:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 02:58:08 2024 Received: from localhost ([127.0.0.1]:44180 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKuhM-0005XB-H1 for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 02:58:08 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52704) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sKuhJ-0005We-Fp for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 02:58:07 -0400 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 <eliz@HIDDEN>) id 1sKuhC-0004Zq-Lt; Sat, 22 Jun 2024 02:57:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Dd3ewHRw01Kgt0A14C9OVmJsgI9Bv1UTFTDpw48S3c4=; b=mrE7JfhO0/Yl dvFfNYXBVBvShnPv8grhRW/ZhtlZ2FMIyffa3iIWZAMUZxCqLtZR51pFuRKDd+PumdMaoE3ceoBVG GlH5Gdhnp/nDpSjxoAwd4tV39YRolrF3QYqxX366DTUeLM4qLy8T6cRQhs8IEUJg/uBWlgojlVoDs e6PPoFFlRGS0AwGczaR7vfNI2fIRnTnCgrUeLnFDRf8eCL4wTWE06y8SZ1dVv0LckTHfEdw3vUkbp hMgFRInT2J8D5X3yqM97X5+l5CSjqOSRZNaqIyHnrcM2kRJH3mEBbdIliz6eo7L6jmxpL21FZCk/M ydm0ZPZKwEnsMcTshEcloQ==; Date: Sat, 22 Jun 2024 09:57:55 +0300 Message-Id: <86ed8pjwgc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 21 Jun 2024 17:06:31 -0400) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <86y16ylrj9.fsf@HIDDEN> <jwv5xu210i4.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org > Date: Fri, 21 Jun 2024 17:06:31 -0400 > > > commit 8783700b23e70874c4996908bf02c010ae6f3fe1 > > Author: Stefan Monnier <monnier@HIDDEN> > > AuthorDate: Tue Aug 2 10:38:53 2022 -0400 > > Commit: Stefan Monnier <monnier@HIDDEN> > > CommitDate: Tue Aug 2 13:06:51 2022 -0400 > > > > * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1 > > > > It changed the comparison operator in two places in marker.c. > > > > Curiously, the log message doesn't even mention the change in > > marker.c, which could be a sign that this change was not intended to > > be installed. Stefan, did you intend to install it, and if so, do you > > have any comments about this bug report? > > Hmm... can't remember why/how it ended up in the above commit. > Looks like an oversight. But the change should be harmless: the > `eassert` should make sure that the comparison gives the same answer > either way (and AFAICT if/when the new comparison gives a different > answer from the old code, the old code will loop until it segfaults). Mitchell, can you try reverting that change, and see if that affects performance in your case? > > I'm a bit confused by the fact that I don't see the slowdown on my > > machine, but maybe there are other factors at work here that hide > > the regression. > > The byte<->char conversion code is affected by many unrelated moving > parts, so it can be difficult to come up with a reproducible recipe. But in this case, we did that in "emacs -Q" and with a specific test file that was posted and used. What other variables can affect this recipe? Do you see the slow response on your machine, for example, when running this recipe?
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 22 Jun 2024 05:25:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 01:25:32 2024 Received: from localhost ([127.0.0.1]:44136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKtFk-0003K9-4K for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:25:32 -0400 Received: from lists.gnu.org ([209.51.188.17]:39310) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1sKtFh-0003K1-Mz for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:25:30 -0400 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 <gerd.moellmann@HIDDEN>) id 1sKtDc-00043s-53 for bug-gnu-emacs@HIDDEN; Sat, 22 Jun 2024 01:23:20 -0400 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>) id 1sKtDa-00068y-HK; Sat, 22 Jun 2024 01:23:19 -0400 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-a6fe118805dso28891166b.3; Fri, 21 Jun 2024 22:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719033796; x=1719638596; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=; b=IRdGOcjQPAFCZTAGglBcxaxB5M8POfjkv8Iv4/bALkU2/cYwzPvL0GYlzfTArAR/kJ Lw/hr1ujo/LObqkjIK446BteXllN3/b33czFfjo2wSIBr6Ujf+A5VY8puTHoHcA4r/84 Jrcsp0F0foFYVmGY7bsuIE05ry5yaDcr30w8ScpHH1gucwZ7sGu/bELoFRyRNRt9S/qb tTMXVEOnpWkwWCJ4iDJMcDNzhM2kt4DYQOydjo6tJcGvZf5ezMozXG8q8Cwg+ypdyOib HS/i77PE0PqlA8jxFhk840JjZYhdiqgb7wTkaUXVN/wbdvfvuWhUoJJ+o0Bw1NxqIHQC mu3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719033796; x=1719638596; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=; b=e580+bSzuHkQUbPh210tuf3H7owvhSyOt4eqLg2KuYQnG5esJ66blNCPCugKgFKidj XKFN+ok9fGCOnlI0MLBOQHo6dcsW4ya+LwGgBh80ZKb0GqgXqjRwpNzOWXdxKpgmjjW8 fOnCqLHs1RE5eNTRvVMO/mf4bZ9ZdODvxSS6J1SKYB8q9d1KN5vVtnr+GWn4wSf0DJBk lrTj+5vu4tZeFKMMtM5o3KKPBZV8+xjf3X39oPdvJyLm6BgSViTTUCkspyyQIxx4a2NB JSraKWI4qh7dBL3U23V439/Mhe6zbEREErVnE0hldNIRTpVMNqDd31j5aJiZO4/+DM+6 Gzsg== X-Forwarded-Encrypted: i=1; AJvYcCXADA3O+lu8DE9dcsC5AZI+ZZN766ygluszBY0N2ihD/mLUb18wk1LPU3YiiHt3qkSWQFLsoL4+IltmE18= X-Gm-Message-State: AOJu0Yzfyi4qWwVc4/Ds+lr2b+oqmmVXQTcamBLqAb4zcXx8VSE5dGEd CZANSP1TzmIUw09M1o/CjxJ2Ng2wbgvm3VQQZ94pP+2DLgLH2Ld1cVSZIQ== X-Google-Smtp-Source: AGHT+IG2WVYKgEBKLBd7UdGSHNxjn/Q8Gi7fw2kh0YPXGKc8JzoK+TmqQk5w1wSPyrSrYiyvw7dlcA== X-Received: by 2002:a17:906:a847:b0:a6f:e36:aba8 with SMTP id a640c23a62f3a-a6fab6488b8mr533431466b.33.1719033795681; Fri, 21 Jun 2024 22:23:15 -0700 (PDT) Received: from pro2.fritz.box (pd9e364bf.dip0.t-ipconnect.de. [217.227.100.191]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf560746sm151406266b.156.2024.06.21.22.23.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jun 2024 22:23:15 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Fri, 21 Jun 2024 16:53:04 -0400") References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> Date: Sat, 22 Jun 2024 07:23:14 +0200 Message-ID: <m2y16x4kl9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=gerd.moellmann@HIDDEN; helo=mail-ej1-x62d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit Cc: Mitchell <mitchellahren@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: > [ In retrospect I wish we'd stuck to the Emacs-20.1 design where > chars=3Dbytes. I know it introduced a lot of breakage (and it'd be even > worse now), but it is The Right Thing=E2=84=A2 if you can ignore backwa= rd > compatibility. ] (Wasn't that pre-20? I remember having a ton of problems with the "new" redisplay when I ported it 19 to 20.) +1 (And make character a type.)
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 22 Jun 2024 05:24:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 22 01:24:25 2024 Received: from localhost ([127.0.0.1]:44132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKtEe-0003IN-Oc for submit <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:24:24 -0400 Received: from mail-ej1-f43.google.com ([209.85.218.43]:54318) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1sKtEb-0003I9-MX for 71644 <at> debbugs.gnu.org; Sat, 22 Jun 2024 01:24:23 -0400 Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a6ef46d25efso305585766b.0 for <71644 <at> debbugs.gnu.org>; Fri, 21 Jun 2024 22:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719033796; x=1719638596; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=; b=KVHyxtT4fexhBZ/n9ZsV6nzg1pezRKXUOQOTeTD9+lVu+SrqjFbkO2JyAx5eBQlAUV C5ayk3/ZC9wyLyftBW0Q2zUuyGnP6WsEwnUayLGYYn6ESbzBeZged1xCONppzHlAI/vh hfl618WgZCMRYjvr+lCBCCfan4CupVWsJE97VaY5dC7yf0EouM6KC1ZlqGxcpGpkniDj q48/Z4TEuhe40loNbM2rz6HDv+xS4zZsQVQq6zazpZO3BpcCDK5/VVOmxOYk9UDFYdTa wg2gdI+CLHJYaF+iZsa9sbQzrK7H3TgXEG2Wpzkxg86uG8z+WG5YZgPgw/n3QI7iAJO7 p9Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719033796; x=1719638596; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=u6hmOaywPI5QI2kwH6MYJN3Y6DVMkiS7od6QATFN0pY=; b=vzewzQbUp6EJfQKRSlCqr4FpLAyHzVxgFrw6uaYvMhmUCaar6E5sSFuNSHGln6DKxc kECKxtkY7eu8jFuvGRnjvOWr8qFaV4hbqOlld3Jv40YKfPqXH87rT65GOp6X+B0eOaur GQaFVhcZAzJAW3Iuw+1k23pmHux2A4dAvSN+leMd2uQxPnJ47hnvZ8TASQ1kH1HfE/TV x1GPPoOwcXz5+3aCMADM8eNDafF23GhwuisdgsfpQRoiLm0itWXzo7KsQIdjAuS2QRB6 7y93OXyeKxtoChvmat+yX5TCpcIByT8W1x/fU5GXnrIAugnqJE7jo4AvXmxtKP9+CUjw o8SA== X-Forwarded-Encrypted: i=1; AJvYcCXGGYONMZP+pYzWeH/yMY2RkYlgrD7Qj9ai9mnb8CdD5PWDqHXLizInPtC9Mg1kuv0+qXu9+MXcVOWDRYi31RaRMZHMDqk= X-Gm-Message-State: AOJu0YzgyS9cM76e/q9NoVwweoSZiMK4CmpZ1c8K07mwK5X4vV+MPO0s RjgIwWkPJACUMdyRx6FGO+euaMCFaY+fNHQtE2GiZbtPysbVIjATbkv0kg== X-Google-Smtp-Source: AGHT+IG2WVYKgEBKLBd7UdGSHNxjn/Q8Gi7fw2kh0YPXGKc8JzoK+TmqQk5w1wSPyrSrYiyvw7dlcA== X-Received: by 2002:a17:906:a847:b0:a6f:e36:aba8 with SMTP id a640c23a62f3a-a6fab6488b8mr533431466b.33.1719033795681; Fri, 21 Jun 2024 22:23:15 -0700 (PDT) Received: from pro2.fritz.box (pd9e364bf.dip0.t-ipconnect.de. [217.227.100.191]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a6fcf560746sm151406266b.156.2024.06.21.22.23.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Jun 2024 22:23:15 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier via's message of "Fri, 21 Jun 2024 16:53:04 -0400") References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> <87h6dmbyy2.fsf@localhost> <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN> Date: Sat, 22 Jun 2024 07:23:14 +0200 Message-ID: <m2y16x4kl9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71644 Cc: Mitchell <mitchellahren@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> writes: > [ In retrospect I wish we'd stuck to the Emacs-20.1 design where > chars=3Dbytes. I know it introduced a lot of breakage (and it'd be even > worse now), but it is The Right Thing=E2=84=A2 if you can ignore backwa= rd > compatibility. ] (Wasn't that pre-20? I remember having a ton of problems with the "new" redisplay when I ported it 19 to 20.) +1 (And make character a type.)
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 21:06:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 21 17:06:41 2024
Received: from localhost ([127.0.0.1]:43914 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sKlSz-0005R3-1W
for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 17:06:41 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26745)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sKlSw-0005Qp-TO
for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 17:06:39 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D836980C8E;
Fri, 21 Jun 2024 17:06:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719003992;
bh=81OivFs9r+nGAZQWPRJLhFVkh+8Iikb80wJuUJcMCFo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=CYxWo/mmCerOGaEVPLuPR1HQbCCB1VfOX/2Iu9kZKiYFfkpQAxIEy9cZIkb4trPvd
EZbRrQot0RY6FeTLV4q0HAXmdkjRmERepMFVHq2axC7dK8dMZhoozMvLl/ZGWxJhyZ
dl5YtT4RWbK8XJLBDGgwwasVGXQ4MDsPjfGEBG/GSWBHMMrfR5EWHxX7Fb209ocUpJ
C79tQRJH+w79YdBoBUch1RfKUkeye1aOL+LcxNcGh4x4MbfJKpkOUullT66Ca42FBT
NIFEoY/+p3ZFwwz2Dh6aP0eESdDCyM4D4BRDn3KwJYuirr7DJZpoCeRXl7vcTFmNY6
B1hq9noPuhE2A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A7940807F5;
Fri, 21 Jun 2024 17:06:32 -0400 (EDT)
Received: from asado (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 61AE51202B5;
Fri, 21 Jun 2024 17:06:32 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <86y16ylrj9.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 21 Jun
2024 09:48:58 +0300")
Message-ID: <jwv5xu210i4.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<86y16ylrj9.fsf@HIDDEN>
Date: Fri, 21 Jun 2024 17:06:31 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.086 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> commit 8783700b23e70874c4996908bf02c010ae6f3fe1
> Author: Stefan Monnier <monnier@HIDDEN>
> AuthorDate: Tue Aug 2 10:38:53 2022 -0400
> Commit: Stefan Monnier <monnier@HIDDEN>
> CommitDate: Tue Aug 2 13:06:51 2022 -0400
>
> * src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
>
> It changed the comparison operator in two places in marker.c.
>
> Curiously, the log message doesn't even mention the change in
> marker.c, which could be a sign that this change was not intended to
> be installed. Stefan, did you intend to install it, and if so, do you
> have any comments about this bug report?
Hmm... can't remember why/how it ended up in the above commit.
Looks like an oversight. But the change should be harmless: the
`eassert` should make sure that the comparison gives the same answer
either way (and AFAICT if/when the new comparison gives a different
answer from the old code, the old code will loop until it segfaults).
> I'm a bit confused by the fact that I don't see the slowdown on my
> machine, but maybe there are other factors at work here that hide
> the regression.
The byte<->char conversion code is affected by many unrelated moving
parts, so it can be difficult to come up with a reproducible recipe.
Stefan
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 20:53:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 21 16:53:17 2024
Received: from localhost ([127.0.0.1]:43900 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sKlG0-00056o-U0
for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 16:53:17 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48775)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sKlFx-00056Z-7o
for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 16:53:15 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6A87880C8E;
Fri, 21 Jun 2024 16:53:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1719003185;
bh=7AfMU+VaclZfW0lsebWgyaqBfx88fEvVq2+zFEvVelw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=SLir+/rYCHh0m8eybxj4gw2rEsnZLCHnlvPSVVQmcnLztMfQ+39YjnwNwOpR+Dkpa
O22Vxnwag5FUVWn46YMRkar6f79k57/esvHdH3ayqweM6IMftK6rIwHCZ7i53/mmBK
DPaplKDeCRiXaUqatH/S2OlcHWuhMMTw+pexbZBF+sc74zKUwGud7JWiQ/3X451MCD
6h22oGsAu1h4kauQDg0bV/J7EOt5zWHTvBiUgVb6snMRlUr76sbSh4rcI7XUQ2fH1Z
l1hs864qZhgfINFG0Wxl43+IjYBtVPJ1mOpIKH2xXmXRaYuXKOa4VR8gBpMSZRO2mn
8lk6dpu/vP9Rw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D4D46801D8;
Fri, 21 Jun 2024 16:53:05 -0400 (EDT)
Received: from asado (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8E2781201A6;
Fri, 21 Jun 2024 16:53:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <87h6dmbyy2.fsf@localhost> (Ihor Radchenko's message of "Fri, 21
Jun 2024 06:19:01 +0000")
Message-ID: <jwvbk3u12t1.fsf-monnier+emacs@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
<87h6dmbyy2.fsf@localhost>
Date: Fri, 21 Jun 2024 16:53:04 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.087 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Mitchell <mitchellahren@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>From 0bafd288faee8cae33fe4a122f6e3ac73ec10d60 Mon Sep 17 00:00:00 2001
> Message-ID: <0bafd288faee8cae33fe4a122f6e3ac73ec10d60.1718950719.git.yant=
ar92@HIDDEN>
> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Sun, 23 Apr 2023 21:31:46 +0200
> Subject: [PATCH] * src/marker.c (buf_bytepos_to_charpos): Limit marker se=
arch
>
> Limit searching across buffer markers to first 50 markers and thus
> avoid performance scaling with the number of markers.
>
> I got 5x `re-search-forward' speed improvement in my setup with this
> dumb change.
Hmm... of course, there'd likely be other circumstances where it would
make it 5x slower. E.g. in a large buffer, doing a forward search from
the middle of the buffer when the first 50 markers happen to all be near
the beginning of the buffer will mean that we always use the "slow path"
which scans all the bytes between PT and the position of interest to
count the number of chars therein.
BTW, we already stop after at most N/50 markers where N is the smallest
distance between the position of interest and point/bob/eob/gap (oh and
the position of the last conversion). So it seems that in your test,
this distance N is >2500. Also when that distance is >5000 we create
a new marker, so next time around that position should be at the
beginning of the marker-list. So I wonder what happens in your test:
why do we jump "very far" (more than 2500) between each call to the
conversion function? Also, maybe we should increase
BYTECHAR_DISTANCE_INCREMENT? ]
This byte_to_char and char_to_byte conversion business is a real PITA.
[ In retrospect I wish we'd stuck to the Emacs-20.1 design where
chars=3Dbytes. I know it introduced a lot of breakage (and it'd be even
worse now), but it is The Right Thing=E2=84=A2 if you can ignore backward
compatibility. ]
Using markers as a cheap cache of conversions was a cute hack but we
really need to replace it.
Some options that come to mind:
- Keep the tradition of abusing an existing data structure, and stash
the bytepos info inside the overlay tree or the text properties.
This way the conversion is bounded by O(log BUFFERSIZE).
- Use a dedicated data-structure. E.g. a pair of array-with-a-gap
(one indexed by BYTEPOS/STEP the other indexed by CHARPOS/STEP, where
STEP would be a large enough constant to make those arrays cheap yet
small enough that the remaining scan is cheap).
This way the conversion is O(STEP), i.e. "constant-time".
BTW, among my various local hacks, I've been using the hack below, which
aims to randomize the order in our markers-list, so as to minimize the
risk that we have to wade through lots of markers all clumped around the
same position. I don't think it does a good job of it, but maybe we can
improve the execution of this idea, tho it still doesn't help if there's
no GC involved.
BTW, if/when we use some other data-structure to convert bytes<->chars,
then we could presumably get rid of our markers-list and stash markers
inside our overlay tree (basically represent them as degenerate overlays
with beg=3D=3Dend and no properties).
Stefan
diff --git a/src/alloc.c b/src/alloc.c
index 9304e4e42bb..07409e7cfc3 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -7836,10 +7514,22 @@ sweep_symbols (void)
unchain_dead_markers (struct buffer *buffer)
{
struct Lisp_Marker *this, **prev =3D &BUF_MARKERS (buffer);
+ /* In order to try and avoid worst case behaviors in buf_charpos_to_byte=
pos
+ we try and randomize the order of markers here. */
+ unsigned i =3D 4;
=20
while ((this =3D *prev))
if (vectorlike_marked_p (&this->header))
- prev =3D &this->next;
+ {
+ if (!shuffle_markers || i++ % 8)
+ prev =3D &this->next;
+ else
+ { /* Move this one to front, just to shuffle things a bit. */
+ *prev =3D this->next;
+ this->next =3D BUF_MARKERS (buffer);
+ BUF_MARKERS (buffer) =3D this;
+ }
+ }
else
{
this->buffer =3D NULL;
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 06:49:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 21 02:49:15 2024
Received: from localhost ([127.0.0.1]:56716 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sKY5D-0003Tc-Ja
for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:49:15 -0400
Received: from eggs.gnu.org ([209.51.188.92]:46302)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1sKY5B-0003TO-U0
for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:49:15 -0400
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 <eliz@HIDDEN>)
id 1sKY52-0002oj-1n; Fri, 21 Jun 2024 02:49:04 -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=Z0J8aPuHrE+3ohIFzBCUze+l9/TkY/EFX7Xi8cdRR5w=; b=DHd/MskpgbARbUXnUWzR
9BluJGLN2atV2zlCB11Rcj9vklRIl/2ghgmajBiXl1Atmaq9Qcwxl0BMC4OXiVzccymVRi7tkFT1e
anBwoLk4hdV1ow74skNhbPfZsICOeeLDk5CJgifcFdkBidntv3bqmUAb0LJgNDVLT++Y/bHRGgUii
vQPsKV73CONAd0b7wbIgVj/fhsqob/F068/Ve58AWdnikyX1kfjDs2B/S+vwvPj0j6o2mtZOxYnFB
9H/xI1VgMuiifsw4WEBKh0JLiEO82+JZ8In6jHnEKvNKT68KdSR3eKmYVYS70w0RuVmb+jSo62Jhu
TOYxGSjlNxzWaQ==;
Date: Fri, 21 Jun 2024 09:48:58 +0300
Message-Id: <86y16ylrj9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Mitchell <mitchellahren@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
(message from Mitchell on Thu, 20 Jun 2024 20:46:51 -0600)
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers
beginning in emacs 29+
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Mitchell <mitchellahren@HIDDEN>
> Date: Thu, 20 Jun 2024 20:46:51 -0600
> Cc: 71644 <at> debbugs.gnu.org
>
> > If you remove all the non-ASCII characters from the Org file, does the
> > slowdown go away?
>
> Eli, that solved it! The new test file is at
> https://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2. I replaced every non-ASCII character
> with an "a" so the file still has the same number of total characters, and in my emacs 30.0 50 build (as of
> 2024-05-25), doing Steps 1 to Step 7 gives me abbrev expansions that are as lighting fast as in emacs 28.2!
>
> So what now? Do you think you can solve what’s going on in the backend so bigger buffers with markers and
> non-ASCII characters don’t exhibit this slowness in the latest emacs?
The fact that the problem goes away when you remove non-ASCII
characters is a pretty convincing argument in favor of your theory
that markers are involved. Because Emacs consults the buffer's
markers whenever it needs to convert character positions to byte
positions or vice versa, which is done _a_lot_.
The only significant change I see in markers code that could be
related to converting character to byte positions is this:
commit 8783700b23e70874c4996908bf02c010ae6f3fe1
Author: Stefan Monnier <monnier@HIDDEN>
AuthorDate: Tue Aug 2 10:38:53 2022 -0400
Commit: Stefan Monnier <monnier@HIDDEN>
CommitDate: Tue Aug 2 13:06:51 2022 -0400
* src/xdisp.c (redisplay_window): Use BEG rather than hard coding 1
It changed the comparison operator in two places in marker.c.
Curiously, the log message doesn't even mention the change in
marker.c, which could be a sign that this change was not intended to
be installed. Stefan, did you intend to install it, and if so, do you
have any comments about this bug report?
I'm a bit confused by the fact that I don't see the slowdown on my
machine, but maybe there are other factors at work here that hide the
regression.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 06:17:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 21 02:17:31 2024
Received: from localhost ([127.0.0.1]:56675 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sKXaU-0002hK-U8
for submit <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:17:31 -0400
Received: from mout01.posteo.de ([185.67.36.65]:56271)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <yantar92@HIDDEN>) id 1sKXaS-0002h4-CW
for 71644 <at> debbugs.gnu.org; Fri, 21 Jun 2024 02:17:29 -0400
Received: from submission (posteo.de [185.67.36.169])
by mout01.posteo.de (Postfix) with ESMTPS id 45632240028
for <71644 <at> debbugs.gnu.org>; Fri, 21 Jun 2024 08:17:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
t=1718950638; bh=p/bafi0s/IVL59N0a7/DDyV67Fu2QwH8eF99U0uh2YE=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
From;
b=EVA9jjZPI9AS/yNpksmwxYnhmqMFV+w0ka0KLA1z7FPH6Ar2PZsnDi8HsA5FgR00n
k9/0eLvJC+kSsIT1frBWSsgrUJ5cz1aO5Q6lWqxX8EYEmL8F43syYScRBxJzFzUVAP
jomODkajm0bwOY0HnpvL+z6xBclawcXkBgJYwgGzc8rCU+gl/udqXxAwIvUL1Lkx+d
di049qcdXUTFCUAZKX0r3rc2/OcsXpJ4V6S41ToX0slaZRPLJBHspkF8PXIp8edTVt
bNf1C3yb4nhTqVHfxjR/7qVdGGWGlV8RxZkPDDINbdds0e8GwTEO04n+kgNL6Qu53C
2LIpgSuO9MYOQ==
Received: from customer (localhost [127.0.0.1])
by submission (posteo.de) with ESMTPSA id 4W56b13G9lz9rxR;
Fri, 21 Jun 2024 08:17:17 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
To: Mitchell <mitchellahren@HIDDEN>
Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with
markers beginning in emacs 29+
In-Reply-To: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN>
<86ed8tozub.fsf@HIDDEN>
<CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN>
<86jzijmo5a.fsf@HIDDEN>
<CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN>
Date: Fri, 21 Jun 2024 06:19:01 +0000
Message-ID: <87h6dmbyy2.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71644
Cc: Eli Zaretskii <eliz@HIDDEN>, 71644 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
Mitchell <mitchellahren@HIDDEN> writes:
>> If you remove all the non-ASCII characters from the Org file, does the
>> slowdown go away?
>
> Eli, that solved it! The new test file is at
> https://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2. I
> replaced every non-ASCII character with an "a" so the file still has the
> same number of total characters, and in my emacs 30.0 50 build (as of
> 2024-05-25), doing Steps 1 to Step 7 gives me abbrev expansions that are as
> lighting fast as in emacs 28.2!
Hmm. Then, does the attached patch help?
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-src-marker.c-buf_bytepos_to_charpos-Limit-marker-sea.patch
From 0bafd288faee8cae33fe4a122f6e3ac73ec10d60 Mon Sep 17 00:00:00 2001
Message-ID: <0bafd288faee8cae33fe4a122f6e3ac73ec10d60.1718950719.git.yantar92@HIDDEN>
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Sun, 23 Apr 2023 21:31:46 +0200
Subject: [PATCH] * src/marker.c (buf_bytepos_to_charpos): Limit marker search
Limit searching across buffer markers to first 50 markers and thus
avoid performance scaling with the number of markers.
I got 5x `re-search-forward' speed improvement in my setup with this
dumb change.
---
src/marker.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/marker.c b/src/marker.c
index f016bf9c088..4d7d6621513 100644
--- a/src/marker.c
+++ b/src/marker.c
@@ -354,8 +354,10 @@ buf_bytepos_to_charpos (struct buffer *b, ptrdiff_t bytepos)
if (b == cached_buffer && BUF_MODIFF (b) == cached_modiff)
CONSIDER (cached_bytepos, cached_charpos);
- for (tail = BUF_MARKERS (b); tail; tail = tail->next)
+ int i = 0;
+ for (tail = BUF_MARKERS (b); tail && i < 50; tail = tail->next)
{
+ i++;
CONSIDER (tail->bytepos, tail->charpos);
/* If we are down to a range of 50 chars,
--
2.45.1
--=-=-=
Content-Type: text/plain
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 21 Jun 2024 02:48:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 22:48:41 2024 Received: from localhost ([127.0.0.1]:53188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKUKO-0004g5-QE for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 22:48:41 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:47521) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mitchellahren@HIDDEN>) id 1sKUKM-0004fr-OB for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 22:48:39 -0400 Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2eaafda3b5cso17077531fa.3 for <71644 <at> debbugs.gnu.org>; Thu, 20 Jun 2024 19:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718938048; x=1719542848; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yhS2iew0iFU2Ggl9J3XfnvRg2RLQCK/Ezv2hMCM4SG8=; b=IO+x3a6ZGyeXRPFhFhlSUMb6UQRenYU4PvXPchdD4l96Q8MStyZyF4H/1tsDp+ZEaK BTN0RTHQhkN/ZL5HtSe4iqC+SpzuQWcMiQ/dYEmsoDLcY6yo7GPKReyuiC5/fgwuOjzH Dg8t5fBgXUEuejrMFyyjPuX5eWnvVuirnx1f/2p91QCZIChExwExDGpTLQ3CASlp17/8 p5mq8mMYoWx2emiq0DXbSE+BpiXuBa01eQ1WZcLWJshhOCUVvpETL+9ihbLKeNPXSIvR LMyAiWtOl6xJcuuHjukLuL1otEXdMEHhpj/ZGkJ8jjiCl11cqCDOUJz76+XMQPdLslKD 3ABA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718938048; x=1719542848; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yhS2iew0iFU2Ggl9J3XfnvRg2RLQCK/Ezv2hMCM4SG8=; b=wIOI21KWKZXZ+q01Lo82KH7GZ5GYzQhXJ5glYsXqn3qxfiXoEuveyWzeQrFZiSoPX0 HVv2GnCu2r/yq4GqTm94gqqZrZseLyvEAbiEat3TE9/gJCnZXcCxDA42Oeei5nMiz5QW uqJHxBVsIS/e511W1CJBtAcGpAeY/2jEoUw3cXLMYHnHQ7ZKtHduXNQRHK73oWU4w1Wr wTfjkaFMQPwXMRj3m6lTGhQ9U89Ubj06DuaFrFWmkXG+sE0iviTPvUwq1uKkZwMlqw32 RMRg4lFVok0HTVySU5fp5O4AipG9Ua2ifoJHZMoKRHGAb+mXwlsOhrDAmTgGxcEX+1WE DShg== X-Gm-Message-State: AOJu0YxyXnOokd7qswqEOS4VbGJOy0/4xITy1ifUYo6H4Ev9ew7ohYEa Bg5t9PEnJHRKgsSVEoElhy4ckS9apg4/RlElH4WK9eVm4SBscnZ1ZroRfL+0iy9swKHCQ+pjoEs ZotAVUTl57aqbkh23luL6kFt4uYpUVeXwaVc= X-Google-Smtp-Source: AGHT+IH3S5hslLsffp1mzqy6B8jmcCSlEg6pRmQdK+QRnS1FrcpuA3d1KauPm6q4DRoncstidgt/kQjfn6fl1+S3jsU= X-Received: by 2002:a2e:9e4d:0:b0:2ec:1ce8:9a7d with SMTP id 38308e7fff4ca-2ec3ce974bdmr43543891fa.4.1718938048098; Thu, 20 Jun 2024 19:47:28 -0700 (PDT) MIME-Version: 1.0 References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> <86jzijmo5a.fsf@HIDDEN> In-Reply-To: <86jzijmo5a.fsf@HIDDEN> From: Mitchell <mitchellahren@HIDDEN> Date: Thu, 20 Jun 2024 20:46:51 -0600 Message-ID: <CAOQwW=b9ksFiPL6j5wzzea_Hq67xt31ME+rq6KkT96r-LGrigg@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000bf7750061b5d73dc" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000bf7750061b5d73dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > If you remove all the non-ASCII characters from the Org file, does the > slowdown go away? Eli, that solved it! The new test file is at https://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2. I replaced every non-ASCII character with an "a" so the file still has the same number of total characters, and in my emacs 30.0 50 build (as of 2024-05-25), doing Steps 1 to Step 7 gives me abbrev expansions that are as lighting fast as in emacs 28.2! So what now? Do you think you can solve what=E2=80=99s going on in the back= end so bigger buffers with markers and non-ASCII characters don=E2=80=99t exhibit = this slowness in the latest emacs? Thank you again! On Thu, Jun 20, 2024 at 1:04=E2=80=AFPM Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Mitchell <mitchellahren@HIDDEN> > > Date: Thu, 20 Jun 2024 12:57:58 -0600 > > Cc: 71644 <at> debbugs.gnu.org > > > > > Why did you decide the problem was due to markers? I see a single > > > change in the implementation of markers in Emacs 29 as compared to > > > Emacs 28, and no changes at all in Emacs 30 (except one that affects > > > the Android, I think). > > > > I thought it was markers because (1) overwriting a few functions in > counsel.el to be the versions at > > https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260 so > that counsel-outline cleaned up the > > markers it created caused the bug to go away, and (2) the bug also > exists when instead of counsel-outline at > > Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), > and `org-refile-use-cache` seems to create > > many markers in the buffer. But maybe counsel-outline and org-refile ar= e > both doing something else that > > cause the bug. (FWIW I did also notice that the abbrev expansions were > slightly quicker in Step 7 after using > > org-refile than after counsel-outline...) > > If you remove all the non-ASCII characters from the Org file, does the > slowdown go away? > > > > I _can_ reproduce this in Emacs 29.3, where indeed > > > expanding any of the two abbrevs takes about 0.5 sec to show on the > > > screen. > > > > Abbrev expansions on my machine take longer. When I re-create the bug > with counsel-outline, the abbrevs > > take over a second each to expand. Maybe your hardware is faster than > mine? > > Could be, but twice slower sounds too much to be explained by CPU > speed. > > > > I see 3400 markers created by counsel-outline in this case, which is > > > not too many, IMO. > > > > Interesting, maybe it isn=E2=80=99t markers after all. Can I ask how yo= u count > markers? I couldn=E2=80=99t find anything in the > > docs or online. > > There's a function count_markers in Emacs, it just isn't compiled > unless you compile with -DDEBUG_MARKERS=3D1. So I compiled it and > called it from GDB. > --000000000000bf7750061b5d73dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_signature" data-smart= mail=3D"gmail_signature"><div dir=3D"ltr"><div class=3D"">> If you remov= e all the non-ASCII characters from the Org file, does the<br> >=20 slowdown go away?<span class=3D"gmail-im"><br></span></div><div class=3D"">= <span class=3D"gmail-im"><br></span></div><div class=3D""><span class=3D"gm= ail-im">Eli, that solved it! The new test file is at </span><a href=3D"http= s://gist.github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2">https://gist.= github.com/kings2u/2ef0e145f2b42d0a13605b0dc9b6e6e2</a>. <span class=3D"gma= il-im">I replaced every </span> non-ASCII character with an "a" so the file still has the same nu= mber of total characters, and in my emacs 30.0 50 build (as of 2024-05-25),= doing Steps 1 to Step 7 gives me abbrev expansions that are as lighting fa= st as in emacs 28.2!<br></div><div class=3D""><br></div><div class=3D"">So = what now? Do you think you can solve what=E2=80=99s going on in the backend= so bigger buffers with markers and non-ASCII characters=20 don=E2=80=99t exhibit this slowness in the latest emacs? <br></div><div cla= ss=3D""><br></div><div class=3D"">Thank you again!<br></div></div></div></d= iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att= r">On Thu, Jun 20, 2024 at 1:04=E2=80=AFPM Eli Zaretskii <<a href=3D"mai= lto:eliz@HIDDEN">eliz@HIDDEN</a>> wrote:<br></div><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">> From: Mitchell <<a href=3D"mailto:mit= chellahren@HIDDEN" target=3D"_blank">mitchellahren@HIDDEN</a>><br> > Date: Thu, 20 Jun 2024 12:57:58 -0600<br> > Cc: <a href=3D"mailto:71644 <at> debbugs.gnu.org" target=3D"_blank">71644@d= ebbugs.gnu.org</a><br> > <br> > > Why did you decide the problem was due to markers?=C2=A0 I see a = single<br> > > change in the implementation of markers in Emacs 29 as compared t= o<br> > > Emacs 28, and no changes at all in Emacs 30 (except one that affe= cts<br> > > the Android, I think). <br> > <br> > I thought it was markers because (1) overwriting a few functions in co= unsel.el to be the versions at<br> > <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2db= a7260" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/kings2u= /5a8acbf0986f0848be66169d2dba7260</a> so that counsel-outline cleaned up th= e<br> > markers it created caused the bug to go away, and (2) the bug also exi= sts when instead of counsel-outline at<br> > Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), = and `org-refile-use-cache` seems to create<br> > many markers in the buffer. But maybe counsel-outline and org-refile a= re both doing something else that<br> > cause the bug. (FWIW I did also notice that the abbrev expansions were= slightly quicker in Step 7 after using<br> > org-refile than after counsel-outline...)<br> <br> If you remove all the non-ASCII characters from the Org file, does the<br> slowdown go away?<br> <br> > > I _can_ reproduce this in Emacs 29.3, where indeed<br> > > expanding any of the two abbrevs takes about 0.5 sec to show on t= he<br> > > screen.=C2=A0 <br> > <br> > Abbrev expansions on my machine take longer. When I re-create the bug = with counsel-outline, the abbrevs<br> > take over a second each to expand. Maybe your hardware is faster than = mine?<br> <br> Could be, but twice slower sounds too much to be explained by CPU<br> speed.<br> <br> > > I see 3400 markers created by counsel-outline in this case, which= is<br> > > not too many, IMO. <br> > <br> > Interesting, maybe it isn=E2=80=99t markers after all. Can I ask how y= ou count markers? I couldn=E2=80=99t find anything in the<br> > docs or online.<br> <br> There's a function count_markers in Emacs, it just isn't compiled<b= r> unless you compile with -DDEBUG_MARKERS=3D1.=C2=A0 So I compiled it and<br> called it from GDB.<br> </blockquote></div> --000000000000bf7750061b5d73dc--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 21:42:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 17:42:21 2024 Received: from localhost ([127.0.0.1]:45201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKPXw-0000QQ-Iz for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 17:42:21 -0400 Received: from mail-ed1-f42.google.com ([209.85.208.42]:46511) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mitchellahren@HIDDEN>) id 1sKN0a-0006LC-Ux for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 14:59:46 -0400 Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-57d10354955so1313901a12.1 for <71644 <at> debbugs.gnu.org>; Thu, 20 Jun 2024 11:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718909915; x=1719514715; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Da/CLkPeVYhCzrNyBouO93PtWeh7bdHs+WlcagmYcxg=; b=gpYizBQqPzKkEvsCBRo2wm3ubm57CJWEwP7OSqr9fMilker4qBQyjBm6OBYxP15sUI nLjAqK9d1PzSbFYJk3fFTt0giHgw/L/+P7c0ffP4jo5KX4BE/1akpHgiNXYDg4+syGBx zXc4Tg15bVpz2juxTQCvkwnJJfXRt5gN1/SMuBYk1tFz2zzSVZeQByjdP2Sr6LkNDsHv nz+z8yh1eOMyuwcgKODn/YTD2UG30HB8GyZHNfS5du0+gPQDnAPRZWWC1n3IbcRfG7tD YJ7oSL+p8FLOkkFVgr3wlPdnnTXaOORdAXfVFw1EygDicbWfgFAKNw1V/eqOR01RmzAt gfuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718909915; x=1719514715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Da/CLkPeVYhCzrNyBouO93PtWeh7bdHs+WlcagmYcxg=; b=I5uJMjTRfw4vDHz0U/FFpzUG6YaBMKQewpxujkdM+FNeU8gZ4R5HhFa01C0t1MFdP/ OgBFhue++8Enz/PXpVJ+VLSVqn05qJupvi6+WQTEMvnKHqjqkzYrlP5i5bYtuEU1r8tr OmWzcfqh2GXVIXq6SSgQIozBYSGbsJedTvi2KwT2b0Lnp67gPqC0WkJYwvBd6wXerAtn pOObvNS5PuZQ8f6dGG0MRP/kwNrIahoIx/mMv2wNi1BXzyrX6xcyMwgY01AtoSNo9Loz YX3kkBLUdpvqbv/ugG1Rkz9j48roPaudYvV9kljPTjaUqxTl/7l9BgLyyKFPV2rohU8g er1g== X-Gm-Message-State: AOJu0YxgllkX/ik80vnz71oUHQbS+Za25gDRC1U2kYrR0XJmrL2BXo+Q n7/L4uAq8Cfj1QAIWzys3rQ65HjP8zMMSHjoigVw617NL2VOCbS6ArSVdxcxbBHFUZ4NJQI27Rp l8k2vVh6iulwD2JST/EOKj06Ofs93qA7y X-Google-Smtp-Source: AGHT+IE0J+BKB/ag1djCEOe9NNGMiEmeMYVFHI1S4h7aw4na0AY5RfRNwNhKuq6I+6lo6elSLTDeaP+db5vQ2+xOGw4= X-Received: by 2002:a50:d713:0:b0:57c:68fd:2bc9 with SMTP id 4fb4d7f45d1cf-57d07e6bbf0mr3547964a12.3.1718909914844; Thu, 20 Jun 2024 11:58:34 -0700 (PDT) MIME-Version: 1.0 References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> In-Reply-To: <86ed8tozub.fsf@HIDDEN> From: Mitchell <mitchellahren@HIDDEN> Date: Thu, 20 Jun 2024 12:57:58 -0600 Message-ID: <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000e0179f061b56e6b6" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 71644 X-Mailman-Approved-At: Thu, 20 Jun 2024 17:42:19 -0400 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) --000000000000e0179f061b56e6b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you for the response, Eli. > Maybe the reason is that Emacs 30 now > uses Org 9.7.4, whereas you have a local installation of 9.6.30? Upgrading to Org 9.7.4 and reinstalling counsel did seem to improve the abbrev expansion speed slightly on my Emacs 30.0.50 build, at least at first. It=E2=80=99s still not nearly as snappy as 28.2 the longer I edit th= e buffer. I will work on a reliable recipe to recreate this slowness. > Why did you decide the problem was due to markers? I see a single > change in the implementation of markers in Emacs 29 as compared to > Emacs 28, and no changes at all in Emacs 30 (except one that affects > the Android, I think). I thought it was markers because (1) overwriting a few functions in counsel.el to be the versions at https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260 so that counsel-outline cleaned up the markers it created caused the bug to go away, and (2) the bug also exists when instead of counsel-outline at Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), and `org-refile-use-cache` seems to create many markers in the buffer. But maybe counsel-outline and org-refile are both doing something else that cause the bug. (FWIW I did also notice that the abbrev expansions were slightly quicker in Step 7 after using org-refile than after counsel-outline...) > I _can_ reproduce this in Emacs 29.3, where indeed > expanding any of the two abbrevs takes about 0.5 sec to show on the > screen. Abbrev expansions on my machine take longer. When I re-create the bug with counsel-outline, the abbrevs take over a second each to expand. Maybe your hardware is faster than mine? > I see 3400 markers created by counsel-outline in this case, which is > not too many, IMO. Interesting, maybe it isn=E2=80=99t markers after all. Can I ask how you co= unt markers? I couldn=E2=80=99t find anything in the docs or online. On Wed, Jun 19, 2024 at 6:57=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote: > > From: Mitchell <mitchellahren@HIDDEN> > > Date: Tue, 18 Jun 2024 23:25:18 -0600 > > > > I recently upgraded from emacs 28.2 to 29.3. When I resumed working in = a > large 11MB org-mode file that > > never gave me problems with speed on 28.2, I noticed a severe slowdown > when editing the buffer after > > invoking `counsel-outline`. It took a while for me to isolate the issue= , > but it seems to be caused by the many > > markers that `counsel-outline` creates in the buffer. After invoking th= e > command, every subsequent edit to the > > buffer renders much slower on screen than it did in 28.2. > > > > This problem is not only caused by `counsel-outline`, but other > functions that create a lot of markers in the > > buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I > tried upgrading my system to emacs 30.0.50, > > which I've used to generate this bug report, but the issue persists. > > I cannot reproduce this on my system, with the current master branch, > i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed > expanding any of the two abbrevs takes about 0.5 sec to show on the > screen. But in Emacs 30 it's instantaneous, even though I used an > unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now > uses Org 9.7.4, whereas you have a local installation of 9.6.30? > > Why did you decide the problem was due to markers? I see a single > change in the implementation of markers in Emacs 29 as compared to > Emacs 28, and no changes at all in Emacs 30 (except one that affects > the Android, I think). > > > Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and > 5, and then `profiler-stop` after Step > > 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C > function)` in the `profiler-report`. Using the > > `profiler` at the same points using emacs 28.2, I don=E2=80=99t get a b= ig entry > for `redisplay_internal (C function)`. > > This doesn't necessarily mean the problem is due to the markers (but > doesn't refute that, either). > > I see 3400 markers created by counsel-outline in this case, which is > not too many, IMO. > > > Here are the steps to reproduce the issue: > > > > 1. Start emacs 29.3 (or 30.0.50) with emacs -q. > > 2. Paste the minimal config at > https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de into the > > scratch buffer and eval-buffer. (Note on my system I'm using the > `counsel` version current as of > > counsel-20240502.743, but any recent version will reproduce the bug). > > 3. Open the following big file in org-mode: > > https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f08a9e > > 4. `goto-line` 35. > > 5. `M-x counsel-outline` and simply press enter to navigate point to th= e > headline at line 34. > > 6. Go to the end of the line and press `enter` to start typing on a new > line at line 35. > > 7. Start typing `n` `space`, or `t` `space` several times very fast and > observe how long it takes for the abbrev > > expansions (defined in the minimal config above) to show up on the > screen. > > I didn't want to install all those packages (counsel is just the tip > of the iceberg, it wants you to install ivy and swiper and whatnot), > so I simply unpacked their tarballs from ELPA, and did this instead of > steps 1 and 2 above: > > (add-to-list 'load-path "~/foo/ivy-0.14.2") > (add-to-list 'load-path "~/foo/swiper-0.14.2") > (setq-default abbrev-mode t) > (setq save-abbrevs nil) > (add-hook 'minibuffer-setup-hook (lambda () (setq-local abbrev-mode > nil))) > (define-abbrev global-abbrev-table "n" "and") > (define-abbrev global-abbrev-table "t" "the") > (define-abbrev global-abbrev-table "th" "that") > > M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET > M-x eval-region RET > > Then I did all the rest of steps. As mentioned, I do see the slow > responses in Emacs 29.3, but not in the latest master branch of the > Emacs Git repository. > --000000000000e0179f061b56e6b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Thank you for the response, Eli. <br></div><div><br><= /div><div>> Maybe the reason is that Emacs 30 now<br>> uses Org 9.7.4= , whereas you have a local installation of 9.6.30? <br></div><div><br></div= ><div>Upgrading to Org 9.7.4 and reinstalling counsel did seem to improve t= he abbrev expansion speed slightly on my Emacs 30.0.50 build, at least at f= irst. It=E2=80=99s still not nearly as snappy as 28.2 the longer I edit the= buffer. I will work on a reliable recipe to recreate this slowness. <br></= div><div><br></div><div class=3D""> >=20 =20 Why did you decide the problem was due to markers?=C2=A0 I see a single<br> >=20 =20 change in the implementation of markers in Emacs 29 as compared to<br> >=20 =20 Emacs 28, and no changes at all in Emacs 30 (except one that affects<br> >=20 =20 the Android, I think). <br></div><div><br></div><div>I thought it was marke= rs because (1) overwriting a few functions in counsel.el to be the versions= at <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba= 7260" target=3D"_blank">https://gist.github.com/kings2u/5a8acbf0986f0848be6= 6169d2dba7260</a> so that counsel-outline cleaned up the markers it created= caused the bug to go away, and (2) the bug also exists when=20 instead of counsel-outline=20 at Step 5 I used org-refile (with=20 `org-refile-use-cache` is set to `t`), and `org-refile-use-cache` seems to = create many markers in the buffer. But maybe counsel-outline and org-refile= are both doing something else that cause the bug. (FWIW I did also notice = that the abbrev expansions were slightly quicker in Step 7 after using org-= refile than after counsel-outline...)<br></div><div><br></div><div>>=20 I _can_ reproduce this in Emacs 29.3, where indeed<br> >=20 expanding any of the two abbrevs takes about 0.5 sec to show on the<br> >=20 screen.=C2=A0 <br></div><div><br></div><div>Abbrev expansions on my machine= take longer. When I re-create the bug with counsel-outline, the abbrevs ta= ke over a second each to expand. Maybe your hardware is faster than mine?</= div><div><br></div><div> >=20 =20 I see 3400 markers created by counsel-outline in this case, which is<br> >=20 =20 not too many, IMO. <br></div><div><br></div><div>Interesting, maybe it isn= =E2=80=99t markers after all. Can I ask how you count markers? I couldn=E2= =80=99t find anything in the docs or online.<br></div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 19, 2024= at 6:57=E2=80=AFAM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" targe= t=3D"_blank">eliz@HIDDEN</a>> wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex">> From: Mitchell <<a href=3D"mailto:mitchell= ahren@HIDDEN" target=3D"_blank">mitchellahren@HIDDEN</a>><br> > Date: Tue, 18 Jun 2024 23:25:18 -0600<br> > <br> > I recently upgraded from emacs 28.2 to 29.3. When I resumed working in= a large 11MB org-mode file that<br> > never gave me problems with speed on 28.2, I noticed a severe slowdown= when editing the buffer after<br> > invoking `counsel-outline`. It took a while for me to isolate the issu= e, but it seems to be caused by the many<br> > markers that `counsel-outline` creates in the buffer. After invoking t= he command, every subsequent edit to the<br> > buffer renders much slower on screen than it did in 28.2.<br> > <br> > This problem is not only caused by `counsel-outline`, but other functi= ons that create a lot of markers in the<br> > buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I t= ried upgrading my system to emacs 30.0.50,<br> > which I've used to generate this bug report, but the issue persist= s. <br> <br> I cannot reproduce this on my system, with the current master branch,<br> i.e. Emacs 30.=C2=A0 I _can_ reproduce this in Emacs 29.3, where indeed<br> expanding any of the two abbrevs takes about 0.5 sec to show on the<br> screen.=C2=A0 But in Emacs 30 it's instantaneous, even though I used an= <br> unoptimized build of Emacs 30.=C2=A0 Maybe the reason is that Emacs 30 now<= br> uses Org 9.7.4, whereas you have a local installation of 9.6.30?<br> <br> Why did you decide the problem was due to markers?=C2=A0 I see a single<br> change in the implementation of markers in Emacs 29 as compared to<br> Emacs 28, and no changes at all in Emacs 30 (except one that affects<br> the Android, I think).<br> <br> > Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and= 5, and then `profiler-stop` after Step<br> > 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C funct= ion)` in the `profiler-report`. Using the<br> > `profiler` at the same points using emacs 28.2, I don=E2=80=99t get a = big entry for `redisplay_internal (C function)`.<br> <br> This doesn't necessarily mean the problem is due to the markers (but<br= > doesn't refute that, either).<br> <br> I see 3400 markers created by counsel-outline in this case, which is<br> not too many, IMO.<br> <br> > Here are the steps to reproduce the issue:<br> > <br> > 1. Start emacs 29.3 (or 30.0.50) with emacs -q.<br> > 2. Paste the minimal config at <a href=3D"https://gist.github.com/king= s2u/30b7a22dfa38fe0d5dc18adaf0e5e9de" rel=3D"noreferrer" target=3D"_blank">= https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de</a> into t= he<br> > scratch buffer and eval-buffer. (Note on my system I'm using the `= counsel` version current as of<br> > counsel-20240502.743, but any recent version will reproduce the bug).<= br> > 3. Open the following big file in org-mode:<br> > <a href=3D"https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f= 08a9e" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/kings2u= /c123a30de7e507a153a9500f03f08a9e</a><br> > 4. `goto-line` 35.<br> > 5. `M-x counsel-outline` and simply press enter to navigate point to t= he headline at line 34.<br> > 6. Go to the end of the line and press `enter` to start typing on a ne= w line at line 35.<br> > 7. Start typing `n` `space`, or `t` `space` several times very fast an= d observe how long it takes for the abbrev<br> > expansions (defined in the minimal config above) to show up on the scr= een.<br> <br> I didn't want to install all those packages (counsel is just the tip<br= > of the iceberg, it wants you to install ivy and swiper and whatnot),<br> so I simply unpacked their tarballs from ELPA, and did this instead of<br> steps 1 and 2 above:<br> <br> =C2=A0 (add-to-list 'load-path "~/foo/ivy-0.14.2")<br> =C2=A0 (add-to-list 'load-path "~/foo/swiper-0.14.2")<br> =C2=A0 (setq-default abbrev-mode t)<br> =C2=A0 (setq save-abbrevs nil)<br> =C2=A0 (add-hook 'minibuffer-setup-hook (lambda () (setq-local abbrev-m= ode nil)))<br> =C2=A0 (define-abbrev global-abbrev-table "n" "and")<br= > =C2=A0 (define-abbrev global-abbrev-table "t" "the")<br= > =C2=A0 (define-abbrev global-abbrev-table "th" "that")<= br> <br> =C2=A0 M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET<br> =C2=A0 M-x eval-region RET<br> <br> Then I did all the rest of steps.=C2=A0 As mentioned, I do see the slow<br> responses in Emacs 29.3, but not in the latest master branch of the<br> Emacs Git repository.<br> </blockquote></div> --000000000000e0179f061b56e6b6--
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 19:04:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 15:04:47 2024 Received: from localhost ([127.0.0.1]:40665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKN5S-0000uT-Rq for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 15:04:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45830) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sKN5R-0000uA-7j for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 15:04:45 -0400 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 <eliz@HIDDEN>) id 1sKN5H-0000Zh-LM; Thu, 20 Jun 2024 15:04:35 -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=+gOzL+/K0V4fEvwgUvMChViidGJku0nNXNftSADStNo=; b=f5PzIu1bI8eaSCnCLDK5 CeqgyJ3VQBFycesOLGKDkw5I20gwmGH4oDXvdXe3CAeZzbTIVp5zv/NDov+3OIjn2Sc6Kv7J5mAJR 9DAqWn95ht92qZ/O7wHwtsj0M7dRtGjIaTSU0WChjFCGyrvBt17mqN43h1m4hE0pLeQ7gbMplfq4A Bx9baU+1GTUNMx3DXao6FCgrYtn0A4Gx9yBfUboDO6YvGMMJ+mM5cZnedhzor37Fjo3dNV4jpz9Rl xO26pUMvHeF49IaYGG1f9t+kqFPry1qbpRLmWC285pbAzZ3GTMTKHUMS96iDGv2TmRMUzLmNIe28L QXCrIBlGVuy3QA==; Date: Thu, 20 Jun 2024 22:04:33 +0300 Message-Id: <86jzijmo5a.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Mitchell <mitchellahren@HIDDEN> In-Reply-To: <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> (message from Mitchell on Thu, 20 Jun 2024 12:57:58 -0600) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <CAOQwW=Y4ZVt2FQUcrsnwNhhMBF=40K7y2uRKrnM+xHzgzAGdiA@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Mitchell <mitchellahren@HIDDEN> > Date: Thu, 20 Jun 2024 12:57:58 -0600 > Cc: 71644 <at> debbugs.gnu.org > > > Why did you decide the problem was due to markers? I see a single > > change in the implementation of markers in Emacs 29 as compared to > > Emacs 28, and no changes at all in Emacs 30 (except one that affects > > the Android, I think). > > I thought it was markers because (1) overwriting a few functions in counsel.el to be the versions at > https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260 so that counsel-outline cleaned up the > markers it created caused the bug to go away, and (2) the bug also exists when instead of counsel-outline at > Step 5 I used org-refile (with `org-refile-use-cache` is set to `t`), and `org-refile-use-cache` seems to create > many markers in the buffer. But maybe counsel-outline and org-refile are both doing something else that > cause the bug. (FWIW I did also notice that the abbrev expansions were slightly quicker in Step 7 after using > org-refile than after counsel-outline...) If you remove all the non-ASCII characters from the Org file, does the slowdown go away? > > I _can_ reproduce this in Emacs 29.3, where indeed > > expanding any of the two abbrevs takes about 0.5 sec to show on the > > screen. > > Abbrev expansions on my machine take longer. When I re-create the bug with counsel-outline, the abbrevs > take over a second each to expand. Maybe your hardware is faster than mine? Could be, but twice slower sounds too much to be explained by CPU speed. > > I see 3400 markers created by counsel-outline in this case, which is > > not too many, IMO. > > Interesting, maybe it isn’t markers after all. Can I ask how you count markers? I couldn’t find anything in the > docs or online. There's a function count_markers in Emacs, it just isn't compiled unless you compile with -DDEBUG_MARKERS=1. So I compiled it and called it from GDB.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 16:24:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 12:24:36 2024 Received: from localhost ([127.0.0.1]:35323 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKKaS-0006im-72 for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:24:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57794) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sKKaP-0006iT-4p for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:24:34 -0400 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 <eliz@HIDDEN>) id 1sKKaE-0002Vb-Ly; Thu, 20 Jun 2024 12:24:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=25QGlx6bVOJrABu1oy3gESGJ00jbJPD2SxwwaxHUStI=; b=PDJoFZ8EGIO2 rO4nAWoH35XPQ+70UwWAiCVHTPtA0JtyI5ZqSQJqnzjqc8LewhlK6/Iq0XaHvu2Ci0wG4V5ZkdzC2 2FKLVlikn9IUZwCnS3S9X9yEz1SADE1132DfLEhdWC13F4f6Y/qUT+Dw62/CTwfGxqwxppZ7VbjpN bmPichtAaznKnNFf8u44HQ/PqY1heCqnXB9CrOdn922TIYZ3VJnWOp2thDOxrDfqcXdQlWlv56OBW 321MVV/dcu44ZJ0U4seTP0VfmqyDv22aShP/etxVb4cYbnevWvQHAARBaPaRpA/DR+oClBVmyoBrT KiVKj5+2n6iY93v0AcuECg==; Date: Thu, 20 Jun 2024 19:24:02 +0300 Message-Id: <86v823mvkt.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: yantar92@HIDDEN, mitchellahren@HIDDEN In-Reply-To: <86wmmjmw5r.fsf@HIDDEN> (message from Eli Zaretskii on Thu, 20 Jun 2024 19:11:28 +0300) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <87ed8r912h.fsf@localhost> <86wmmjmw5r.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org > Date: Thu, 20 Jun 2024 19:11:28 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Ihor Radchenko <yantar92@HIDDEN> > > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org > > Date: Thu, 20 Jun 2024 13:49:10 +0000 > > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > > I cannot reproduce this on my system, with the current master branch, > > > i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed > > > expanding any of the two abbrevs takes about 0.5 sec to show on the > > > screen. But in Emacs 30 it's instantaneous, even though I used an > > > unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now > > > uses Org 9.7.4, whereas you have a local installation of 9.6.30? > > > > What if you add > > (setq org-fold-core-style 'text-properties) to your reproducer? > > Then abbrevs don't work (not sure I understand why), so I cannot run > the recipe. Sorry, that was a cockpit error. Now that I fixed that, I can report that the setting you suggested doesn't change anything: I see no delays in Emacs 30.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 16:12:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 12:12:14 2024 Received: from localhost ([127.0.0.1]:34909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKKOT-0006Im-KY for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:12:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41084) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sKKOQ-0006IV-N8 for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 12:12:11 -0400 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 <eliz@HIDDEN>) id 1sKKOD-0000Io-85; Thu, 20 Jun 2024 12:11:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=njrTgbcnkC0luF79xq8yksVLn64lnqxIALUMMTguPlw=; b=AUuOJdzNI1DS lm7UK1oE96ahHzmoolmV0ZwSDHQalt7hyOJTaVPHROdAL4e56+CIDeTFRmn0/1TetNbsbl1XaCqxu ZFDwuwBVJtuUcNq9zTW7prnP1R70HfGIFSwJr1XKqUgzm4VD/vGbqkYYj5DcUJ6OJTAFegKeqFIZY +GeKZ0U6Otr3Qq1rdjmv76HS4xRN0a5J4MxvaSWd2GJSX4TOpt63mi5Y9buzSChtjB9MzmOkg8h+K 0BRqRFQA1et09x0nM2RRrWihCLm/cka7vVbD1FE8E4iZ2MrEMc0/a1LubRa+WHob2yTlLjk928jR6 ALj0UH6AyHiN9kio8vSGxA==; Date: Thu, 20 Jun 2024 19:11:28 +0300 Message-Id: <86wmmjmw5r.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ihor Radchenko <yantar92@HIDDEN> In-Reply-To: <87ed8r912h.fsf@localhost> (message from Ihor Radchenko on Thu, 20 Jun 2024 13:49:10 +0000) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> <87ed8r912h.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: mitchellahren@HIDDEN, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ihor Radchenko <yantar92@HIDDEN> > Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org > Date: Thu, 20 Jun 2024 13:49:10 +0000 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I cannot reproduce this on my system, with the current master branch, > > i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed > > expanding any of the two abbrevs takes about 0.5 sec to show on the > > screen. But in Emacs 30 it's instantaneous, even though I used an > > unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now > > uses Org 9.7.4, whereas you have a local installation of 9.6.30? > > What if you add > (setq org-fold-core-style 'text-properties) to your reproducer? Then abbrevs don't work (not sure I understand why), so I cannot run the recipe.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 20 Jun 2024 13:47:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 20 09:47:40 2024 Received: from localhost ([127.0.0.1]:57306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sKI8a-00010m-Jk for submit <at> debbugs.gnu.org; Thu, 20 Jun 2024 09:47:40 -0400 Received: from mout01.posteo.de ([185.67.36.65]:46563) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <yantar92@HIDDEN>) id 1sKI8Y-00010Q-BE for 71644 <at> debbugs.gnu.org; Thu, 20 Jun 2024 09:47:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id B3092240027 for <71644 <at> debbugs.gnu.org>; Thu, 20 Jun 2024 15:47:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718891246; bh=c/cNoMO3aCPVzwuWK2gxThiKVVJUfmyKHsJXXvF0b/Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=pNWrQ4lVCx3u5BTWc6GDlaB1Fimv37kBP8fEyIV0ru0IFVRIQ1H7NhNSjtIdMo9Q6 0IgxcgS9HD7iuJcwlIiuBXHy6dSc/ucv+Dg4/JWGxJV/HyH6+DBW1aB5GkLY5iI8Et ONzl5u6rWSnPA2smzEcfkI2/VysHmaBvNdZvmCtRrEv8DBMWAMsyMuX9JltpsEln3F sfEBDkAlRAsJEVQLTA1NU9p5HU7GIXVQDHyF37IO3gZ24NlxYGzJZgg+CPmeVuU1lP TOBPaGE/eIQ5AhbXrYzbniidpLWO1OZIZiBOpCi5Ac/X0t+NuqKqC5NKOE6PrZOJ5C TGm1W4errY7TA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W4hcs6DMlz9rxP; Thu, 20 Jun 2024 15:47:25 +0200 (CEST) From: Ihor Radchenko <yantar92@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ In-Reply-To: <86ed8tozub.fsf@HIDDEN> References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> <86ed8tozub.fsf@HIDDEN> Date: Thu, 20 Jun 2024 13:49:10 +0000 Message-ID: <87ed8r912h.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: Mitchell <mitchellahren@HIDDEN>, 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) Eli Zaretskii <eliz@HIDDEN> writes: > I cannot reproduce this on my system, with the current master branch, > i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed > expanding any of the two abbrevs takes about 0.5 sec to show on the > screen. But in Emacs 30 it's instantaneous, even though I used an > unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now > uses Org 9.7.4, whereas you have a local installation of 9.6.30? What if you add (setq org-fold-core-style 'text-properties) to your reproducer? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at 71644) by debbugs.gnu.org; 19 Jun 2024 12:57:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 19 08:57:21 2024 Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sJusL-0007Wu-36 for submit <at> debbugs.gnu.org; Wed, 19 Jun 2024 08:57:21 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1sJusI-0007Wc-6L for 71644 <at> debbugs.gnu.org; Wed, 19 Jun 2024 08:57:19 -0400 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 <eliz@HIDDEN>) id 1sJus9-0001VB-He; Wed, 19 Jun 2024 08:57:09 -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=akuBMyuPWXy9JeGAhpzra7Ga6i2Xe0kCtEXbirHogU8=; b=M2ep+/YhEreJTBcBmUqp jok53vbOvODpXf4ZKax01LuxdEIk+XmlAcgy7qgIBSG89Gpi5RHbFyGGCWpExedy6+K96H6m83Hzp u2qTIIVPeNtrmLKV1KMwFpYaahmUHOrixwWWGCRV4gpARfKrQFVeEnKMZQ40SHlWrCGAww80DidIZ ZHOAPPJ7cmpzex2hBy5MwMaUrgNlOhh5/j7i1D/DcLCJfuPsTAbqQp7w0mJkHQqHgxPCYsFenuv3D zSolPpNWRlrCLN2gNGG0b8PbKuNE1811/n5MF+bGX3zE++C7Vr/SiZ+8qxaPHllzv8oUIIX1AK4Lz F67/PQmiDyfmfQ==; Date: Wed, 19 Jun 2024 15:56:44 +0300 Message-Id: <86ed8tozub.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Mitchell <mitchellahren@HIDDEN> In-Reply-To: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> (message from Mitchell on Tue, 18 Jun 2024 23:25:18 -0600) Subject: Re: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ References: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 71644 Cc: 71644 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Mitchell <mitchellahren@HIDDEN> > Date: Tue, 18 Jun 2024 23:25:18 -0600 > > I recently upgraded from emacs 28.2 to 29.3. When I resumed working in a large 11MB org-mode file that > never gave me problems with speed on 28.2, I noticed a severe slowdown when editing the buffer after > invoking `counsel-outline`. It took a while for me to isolate the issue, but it seems to be caused by the many > markers that `counsel-outline` creates in the buffer. After invoking the command, every subsequent edit to the > buffer renders much slower on screen than it did in 28.2. > > This problem is not only caused by `counsel-outline`, but other functions that create a lot of markers in the > buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I tried upgrading my system to emacs 30.0.50, > which I've used to generate this bug report, but the issue persists. I cannot reproduce this on my system, with the current master branch, i.e. Emacs 30. I _can_ reproduce this in Emacs 29.3, where indeed expanding any of the two abbrevs takes about 0.5 sec to show on the screen. But in Emacs 30 it's instantaneous, even though I used an unoptimized build of Emacs 30. Maybe the reason is that Emacs 30 now uses Org 9.7.4, whereas you have a local installation of 9.6.30? Why did you decide the problem was due to markers? I see a single change in the implementation of markers in Emacs 29 as compared to Emacs 28, and no changes at all in Emacs 30 (except one that affects the Android, I think). > Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and 5, and then `profiler-stop` after Step > 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C function)` in the `profiler-report`. Using the > `profiler` at the same points using emacs 28.2, I don’t get a big entry for `redisplay_internal (C function)`. This doesn't necessarily mean the problem is due to the markers (but doesn't refute that, either). I see 3400 markers created by counsel-outline in this case, which is not too many, IMO. > Here are the steps to reproduce the issue: > > 1. Start emacs 29.3 (or 30.0.50) with emacs -q. > 2. Paste the minimal config at https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de into the > scratch buffer and eval-buffer. (Note on my system I'm using the `counsel` version current as of > counsel-20240502.743, but any recent version will reproduce the bug). > 3. Open the following big file in org-mode: > https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f08a9e > 4. `goto-line` 35. > 5. `M-x counsel-outline` and simply press enter to navigate point to the headline at line 34. > 6. Go to the end of the line and press `enter` to start typing on a new line at line 35. > 7. Start typing `n` `space`, or `t` `space` several times very fast and observe how long it takes for the abbrev > expansions (defined in the minimal config above) to show up on the screen. I didn't want to install all those packages (counsel is just the tip of the iceberg, it wants you to install ivy and swiper and whatnot), so I simply unpacked their tarballs from ELPA, and did this instead of steps 1 and 2 above: (add-to-list 'load-path "~/foo/ivy-0.14.2") (add-to-list 'load-path "~/foo/swiper-0.14.2") (setq-default abbrev-mode t) (setq save-abbrevs nil) (add-hook 'minibuffer-setup-hook (lambda () (setq-local abbrev-mode nil))) (define-abbrev global-abbrev-table "n" "and") (define-abbrev global-abbrev-table "t" "the") (define-abbrev global-abbrev-table "th" "that") M-x load-file RET ~/foo/counsel-0.14.2/counsel.el RET M-x eval-region RET Then I did all the rest of steps. As mentioned, I do see the slow responses in Emacs 29.3, but not in the latest master branch of the Emacs Git repository.
bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 19 Jun 2024 08:02:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 19 04:02:57 2024 Received: from localhost ([127.0.0.1]:36331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1sJqHO-0004DH-BR for submit <at> debbugs.gnu.org; Wed, 19 Jun 2024 04:02:57 -0400 Received: from lists.gnu.org ([209.51.188.17]:46960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <mitchellahren@HIDDEN>) id 1sJnpi-0007ym-2q for submit <at> debbugs.gnu.org; Wed, 19 Jun 2024 01:26:12 -0400 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 <mitchellahren@HIDDEN>) id 1sJnpe-0006DG-97 for bug-gnu-emacs@HIDDEN; Wed, 19 Jun 2024 01:26:06 -0400 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <mitchellahren@HIDDEN>) id 1sJnpW-0006CC-Dx for bug-gnu-emacs@HIDDEN; Wed, 19 Jun 2024 01:26:03 -0400 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-57cb9a370ddso7032476a12.1 for <bug-gnu-emacs@HIDDEN>; Tue, 18 Jun 2024 22:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718774756; x=1719379556; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=pfbAvEyBKnIMMttkJXklUKTf5GjK69Y1RpBBLZezdH8=; b=LxvyMObm3FYKuXsHRO6T1M8xOV7G4HgLsuaFR5rWUTNbXJjVsgezWAHwKdwn26XFSi zHYdF27hKqgjsPWEMKVNhKrXUdw5OJrJ1roagOTQwFXZr4jEvSUHxDtBrxxGj2XWzUjr /r+quPgZ0kBzLCQgvMJjxoytcy0Jzf1dMCV3qyMeUuv5uJBuuyU4J71VTXrT74FvL0uy 05FoXwrtl+PFtEl8O2itM/ENzPCKvlfR/n7efXwGdG4L2m5rwMy+WQTsjLZIOalvOcCX hiM485LY3zGXqFR2T93iDJ/0Pl7vpgvSuqWLxa8RZ/zGCniY864dRMA1J8i9/ovcY65C 8OLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718774756; x=1719379556; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pfbAvEyBKnIMMttkJXklUKTf5GjK69Y1RpBBLZezdH8=; b=I/5ddwl7AyhjwiOsgeEfPHQNBXeklRaVjujQhrrT1afLdnKs+aKovn0D5KGgjIcdJH mnIupUe7Ci2QVaCiR4GlL8jWYM/qywImG175YCbYRFFYNyaJNPb/JyTT4dUGZ3z927nu hKKC0ShixC2hTxMfOh41WZhLf3Q7sFSPCV/jBWo4qCfqnm2rp2hDpkHXM4vL2xWV0XK5 bqS0EYoEEE4Xveu4/w2oX5deL6xOWJYvie5xhDP2he9Ks+ywWUX2BvW/BEl4XZeUPveF ZHm7uOP0QgRt9BwwSzTKklWavRCWIqyeo7Zm+RKbwoFhPcPkxzSyDiwnxGO+EbU38UET 9INQ== X-Gm-Message-State: AOJu0YxyBrhSU3pb/qSNrHsVvZcyUcLGwH3MHkSyzTdNAhgIO4Aykgph s0J/eN7P7u144R3EuzoYeITvrRkHLkG8GaA0TimR/+TuoQJG4hdcsqd3e15ncOq82WAREo7cVhp 6aWEtQhGGl21X4dQhUg0aTvTi+3mT86aQ0yc= X-Google-Smtp-Source: AGHT+IFpBRc9e+sNNfzBalPOt11njWiGjjMYqPKe2I28mejkdyAxLYCLMXEgLJpL2XPCKpKv1xYz7QWvJ1W/2+Z+erA= X-Received: by 2002:a50:ba85:0:b0:57c:61a2:ed47 with SMTP id 4fb4d7f45d1cf-57d07e6b664mr659562a12.24.1718774754758; Tue, 18 Jun 2024 22:25:54 -0700 (PDT) MIME-Version: 1.0 From: Mitchell <mitchellahren@HIDDEN> Date: Tue, 18 Jun 2024 23:25:18 -0600 Message-ID: <CAOQwW=bUhFRK7b4F-RrNRWmuKe4sFazPx++WubSF2scCuvrU1A@HIDDEN> Subject: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ To: bug-gnu-emacs@HIDDEN Content-Type: multipart/alternative; boundary="000000000000b4d60d061b376e60" Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=mitchellahren@HIDDEN; helo=mail-ed1-x536.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Wed, 19 Jun 2024 04:02:52 -0400 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) --000000000000b4d60d061b376e60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I recently upgraded from emacs 28.2 to 29.3. When I resumed working in a large 11MB org-mode file that never gave me problems with speed on 28.2, I noticed a severe slowdown when editing the buffer after invoking `counsel-outline`. It took a while for me to isolate the issue, but it seems to be caused by the many markers that `counsel-outline` creates in the buffer. After invoking the command, every subsequent edit to the buffer renders much slower on screen than it did in 28.2. This problem is not only caused by `counsel-outline`, but other functions that create a lot of markers in the buffer, like `org-refile` if `org-refile-use-cache` is set to `t`. I tried upgrading my system to emacs 30.0.50, which I've used to generate this bug report, but the issue persists. Here are the steps to reproduce the issue: 1. Start emacs 29.3 (or 30.0.50) with emacs -q. 2. Paste the minimal config at https://gist.github.com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de into the scratch buffer and eval-buffer. (Note on my system I'm using the `counsel` version current as of counsel-20240502.743, but any recent version will reproduce the bug). 3. Open the following big file in org-mode: https://gist.github.com/kings2u/c123a30de7e507a153a9500f03f08a9e 4. `goto-line` 35. 5. `M-x counsel-outline` and simply press enter to navigate point to the headline at line 34. 6. Go to the end of the line and press `enter` to start typing on a new line at line 35. 7. Start typing `n` `space`, or `t` `space` several times very fast and observe how long it takes for the abbrev expansions (defined in the minimal config above) to show up on the screen. To verify this slowdown doesn=E2=80=99t occur before invoking `counsel-outl= ine`, when all the markers in the buffer were created, you can try the steps again beginning from Step 1 but after Step 4, jump to Step 7 and see how fast the abbrevs expand. You can also repeat all Steps 1 through 7 above with emacs -q using emacs 28.2 and see that no slowdown occurs at Step 7. Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and 5, and then `profiler-stop` after Step 7, I get a very big entry (e.g., 70%) for `redisplay_internal (C function)` in the `profiler-report`. Using the `profiler` at the same points using emacs 28.2, I don=E2=80=99t get a big e= ntry for `redisplay_internal (C function)`. This slowdown during editing only seems noticeable with larger files, but they don=E2=80=99t have to be 11MB like the first test file. I still notice= a half-second difference at least between emacs 29+ and emacs 28.2 when in Step 3 I instead use the 5MB file at https://gist.github.com/kings2u/7f607bd1069fbe92d611de70b39b936c. It wasn= =E2=80=99t until I reduced the test file to about 2.5MB that I saw emacs 29+ performing edits at the same speed as emacs 28.2 in Step 7 (see this smallest file at: https://gist.github.com/kings2u/2f76d30cea4f12c1bb90fe4f3a90e36e). I=E2=80=99ve tried many different setups to avoid the problem, including di= fferent versions of org-mode, but the only thing that solves it is going back to emacs 28.2, which apparently handles markers more efficiently than 29+. The only way to solve the problem while staying in emacs 29.3 that I=E2=80=99ve= found is to modify `counsel-outline` to not generate markers. (This solution was suggested at https://github.com/abo-abo/swiper/pull/1700. The specific modifications I use can be found at https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba7260). For what it=E2=80=99s worth, I have installed emacs 29.3+ on multiple different mach= ines and observed the exact same behavior. My big 11MB org file is such an integral part of my workflow that I've gone back to emacs 28.2 for now with the hopes that the current version of emacs will go back to handling markers efficiently. Please let me know if I can help further in diagnosing the problem. Thank you for all you do! In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-05-25 built on MITCHELL-16G-TO Repository revision: 57dc1ed665d72bc58befa4853fa479b770fe4fcc Repository branch: master Windowing system distributor 'Microsoft Corp.', version 10.0.19045 System Description: Microsoft Windows 10 Home (v10.0.2009.19045.4412) Configured using: 'configure --prefix=3D/c/emacs --with-modules --without-dbus --with-native-compilation --without-compress-install --with-tree-sitter --with-mailutils --without-gconf --without-gsettings 'CFLAGS=3D-O2 -mtune=3Dnative -march=3Dnative -fomit-frame-pointer'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1252 Major mode: Lisp Interaction Minor modes in effect: global-tab-line-mode: t tab-line-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t abbrev-mode: t Load-path shadows: c:/Users/Mitchell/Emacs/.emacs.d/elpa/transient-20240509.1849/transient hides c:/emacs/share/emacs/30.0.50/lisp/transient c:/Users/Mitchell/Emacs/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides c:/emacs/share/emacs/30.0.50/lisp/bind-key c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -lint hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-lint c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -jump hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-jump c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -ensure hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-ensure c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -diminish hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-diminish c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -delight hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-delight c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -core hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-core c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230426.2324/use-package= -bind-key hides c:/emacs/share/emacs/30.0.50/lisp/use-package/use-package-bind-key c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox hides c:/emacs/share/emacs/30.0.50/lisp/org/ox c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-texinfo hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-texinfo c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-publish hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-publish c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-org hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-org c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-odt hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-odt c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-md hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-md c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-man hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-man c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-latex hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-latex c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-koma-letter hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-koma-letter c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-icalendar hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-icalendar c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-html hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-html c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-beamer hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-beamer c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-ascii hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-ascii c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org hides c:/emacs/share/emacs/30.0.50/lisp/org/org c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-version hides c:/emacs/share/emacs/30.0.50/lisp/org/org-version c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-timer hides c:/emacs/share/emacs/30.0.50/lisp/org/org-timer c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-tempo hides c:/emacs/share/emacs/30.0.50/lisp/org/org-tempo c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-table hides c:/emacs/share/emacs/30.0.50/lisp/org/org-table c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-src hides c:/emacs/share/emacs/30.0.50/lisp/org/org-src c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-refile hides c:/emacs/share/emacs/30.0.50/lisp/org/org-refile c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-protocol hides c:/emacs/share/emacs/30.0.50/lisp/org/org-protocol c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-plot hides c:/emacs/share/emacs/30.0.50/lisp/org/org-plot c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-persist hides c:/emacs/share/emacs/30.0.50/lisp/org/org-persist c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-pcomplete hides c:/emacs/share/emacs/30.0.50/lisp/org/org-pcomplete c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-num hides c:/emacs/share/emacs/30.0.50/lisp/org/org-num c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mouse hides c:/emacs/share/emacs/30.0.50/lisp/org/org-mouse c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mobile hides c:/emacs/share/emacs/30.0.50/lisp/org/org-mobile c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-macs c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macro hides c:/emacs/share/emacs/30.0.50/lisp/org/org-macro c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-loaddefs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-loaddefs c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-list hides c:/emacs/share/emacs/30.0.50/lisp/org/org-list c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-lint hides c:/emacs/share/emacs/30.0.50/lisp/org/org-lint c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-keys hides c:/emacs/share/emacs/30.0.50/lisp/org/org-keys c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-inlinetask hides c:/emacs/share/emacs/30.0.50/lisp/org/org-inlinetask c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-indent hides c:/emacs/share/emacs/30.0.50/lisp/org/org-indent c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-id hides c:/emacs/share/emacs/30.0.50/lisp/org/org-id c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-habit hides c:/emacs/share/emacs/30.0.50/lisp/org/org-habit c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-goto hides c:/emacs/share/emacs/30.0.50/lisp/org/org-goto c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-footnote hides c:/emacs/share/emacs/30.0.50/lisp/org/org-footnote c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold hides c:/emacs/share/emacs/30.0.50/lisp/org/org-fold c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold-core hides c:/emacs/share/emacs/30.0.50/lisp/org/org-fold-core c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-feed hides c:/emacs/share/emacs/30.0.50/lisp/org/org-feed c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-faces hides c:/emacs/share/emacs/30.0.50/lisp/org/org-faces c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-entities hides c:/emacs/share/emacs/30.0.50/lisp/org/org-entities c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-element hides c:/emacs/share/emacs/30.0.50/lisp/org/org-element c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-duration hides c:/emacs/share/emacs/30.0.50/lisp/org/org-duration c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-datetree hides c:/emacs/share/emacs/30.0.50/lisp/org/org-datetree c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-cycle hides c:/emacs/share/emacs/30.0.50/lisp/org/org-cycle c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-ctags hides c:/emacs/share/emacs/30.0.50/lisp/org/org-ctags c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-crypt hides c:/emacs/share/emacs/30.0.50/lisp/org/org-crypt c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-compat hides c:/emacs/share/emacs/30.0.50/lisp/org/org-compat c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-colview hides c:/emacs/share/emacs/30.0.50/lisp/org/org-colview c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-clock hides c:/emacs/share/emacs/30.0.50/lisp/org/org-clock c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-capture hides c:/emacs/share/emacs/30.0.50/lisp/org/org-capture c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-attach hides c:/emacs/share/emacs/30.0.50/lisp/org/org-attach c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-attach-git hides c:/emacs/share/emacs/30.0.50/lisp/org/org-attach-git c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-archive hides c:/emacs/share/emacs/30.0.50/lisp/org/org-archive c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-agenda hides c:/emacs/share/emacs/30.0.50/lisp/org/org-agenda c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol hides c:/emacs/share/emacs/30.0.50/lisp/org/ol c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-w3m hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-w3m c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-rmail hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-rmail c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-mhe hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-mhe c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-man hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-man c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-irc hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-irc c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-info hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-info c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-gnus hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-gnus c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eww hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-eww c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-eshell c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-doi hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-doi c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-docview hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-docview c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bibtex hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-bibtex c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bbdb hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-bbdb c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc hides c:/emacs/share/emacs/30.0.50/lisp/org/oc c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-natbib hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-natbib c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-csl hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-csl c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-bibtex hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-bibtex c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-biblatex hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-biblatex c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-basic hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-basic c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob hides c:/emacs/share/emacs/30.0.50/lisp/org/ob c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-tangle hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-tangle c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-table hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-table c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sqlite hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sqlite c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sql hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sql c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-shell hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-shell c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sed hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sed c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-screen hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-screen c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-scheme hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-scheme c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sass hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sass c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ruby hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ruby c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ref hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ref c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-R hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-R c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-python hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-python c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-processing hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-processing c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-plantuml hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-plantuml c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-perl hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-perl c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-org hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-org c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-octave hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-octave c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ocaml hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ocaml c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-maxima hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-maxima c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-matlab hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-matlab c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-makefile hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-makefile c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lua hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lua c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lob hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lob c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lisp hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lisp c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lilypond hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lilypond c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-latex hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-latex c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-julia hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-julia c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-js hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-js c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-java hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-java c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-haskell hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-haskell c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-groovy hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-groovy c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-gnuplot hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-gnuplot c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-fortran hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-fortran c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-forth hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-forth c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-exp hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-exp c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eval hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-eval c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-eshell c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-emacs-lisp hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-emacs-lisp c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-dot hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-dot c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ditaa hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ditaa c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-css hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-css c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-core hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-core c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-comint hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-comint c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-clojure hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-clojure c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-calc hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-calc c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-C hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-C c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-awk hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-awk Features: (shadow sort mail-extr emacsbug message yank-media puny rfc822 mml mml-sec epa derived gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete org-list org-footnote org-faces org-entities time-date noutline outline ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx org-fold org-fold-core org-keys oc org-loaddefs find-func cal-menu calendar cal-loaddefs org-version org-compat org-macs format-spec counsel xdg xref project dired dired-loaddefs compile text-property-search comint ansi-osc ansi-color swiper ivy delsel ring ivy-faces ivy-overlay colir color modus-vivendi-theme modus-themes cl-extra help-mode tab-line use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core finder-inf easy-mmode epg rfc6068 epg-config gnu-elpa-keyring-update pdf-tools-autoloads tablist-autoloads info package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cus-edit pp cus-start cus-load icons wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty move-toolbar make-network-process native-compile emacs) Memory information: ((conses 16 476739 29195) (symbols 48 26493 0) (strings 32 133104 6737) (string-bytes 1 3784773) (vectors 16 33874) (vector-slots 8 430476 21000) (floats 8 269 15) (intervals 56 554 0) (buffers 992 12)) --000000000000b4d60d061b376e60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I recently upgraded from emacs 28.2 to 29.3. When I resume= d working in a large 11MB org-mode file that never gave me problems with sp= eed on 28.2, I noticed a severe slowdown when editing the buffer after invo= king `counsel-outline`. It took a while for me to isolate the issue, but it= seems to be caused by the many markers that `counsel-outline` creates in t= he buffer. After invoking the command, every subsequent edit to the buffer = renders much slower on screen than it did in 28.2.<br><br>This problem is n= ot only caused by `counsel-outline`, but other functions that create a lot = of markers in the buffer, like `org-refile` if `org-refile-use-cache` is se= t to `t`. I tried upgrading my system to emacs 30.0.50, which I've used= to generate this bug report, but the issue persists. <br><br>Here are the = steps to reproduce the issue:<br><br>1. Start emacs 29.3 (or 30.0.50) with = emacs -q.<br>2. Paste the minimal config at <a href=3D"https://gist.github.= com/kings2u/30b7a22dfa38fe0d5dc18adaf0e5e9de">https://gist.github.com/kings= 2u/30b7a22dfa38fe0d5dc18adaf0e5e9de</a> into the scratch buffer and eval-bu= ffer. (Note on my system I'm using the `counsel` version current as of = counsel-20240502.743, but any recent version will reproduce the bug).<br>3.= Open the following big file in org-mode: <a href=3D"https://gist.github.co= m/kings2u/c123a30de7e507a153a9500f03f08a9e">https://gist.github.com/kings2u= /c123a30de7e507a153a9500f03f08a9e</a><br>4. `goto-line` 35.<br>5. `M-x coun= sel-outline` and simply press enter to navigate point to the headline at li= ne 34.<br>6. Go to the end of the line and press `enter` to start typing on= a new line at line 35.<br>7. Start typing `n` `space`, or `t` `space` seve= ral times very fast and observe how long it takes for the abbrev expansions= (defined in the minimal config above) to show up on the screen.<br><br>To = verify this slowdown doesn=E2=80=99t occur before invoking `counsel-outline= `, when all the markers in the buffer were created, you can try the steps a= gain beginning from Step 1 but after Step 4, jump to Step 7 and see how fas= t the abbrevs expand. You can also repeat all Steps 1 through 7 above with = emacs -q using emacs 28.2 and see that no slowdown occurs at Step 7.<br><br= >Using emacs 29+, when I use `profiler-start` (CPU) between Steps 4 and 5, = and then `profiler-stop` after Step 7, I get a very big entry (e.g., 70%) f= or `redisplay_internal (C function)` in the `profiler-report`. Using the `p= rofiler` at the same points using emacs 28.2, I don=E2=80=99t get a big ent= ry for `redisplay_internal (C function)`.<br><br><div>This slowdown during = editing only seems noticeable with larger files, but they don=E2=80=99t hav= e to be 11MB like the first test file. I still notice a half-second differe= nce at least between emacs 29+ and emacs 28.2 when in Step 3 I instead use = the 5MB file at <a href=3D"https://gist.github.com/kings2u/7f607bd1069fbe92= d611de70b39b936c">https://gist.github.com/kings2u/7f607bd1069fbe92d611de70b= 39b936c</a>. It wasn=E2=80=99t until I reduced the test file to about 2.5MB= that I saw emacs 29+ performing edits at the same speed as emacs 28.2 in S= tep 7 (see this smallest file at: <a href=3D"https://gist.github.com/kings2= u/2f76d30cea4f12c1bb90fe4f3a90e36e">https://gist.github.com/kings2u/2f76d30= cea4f12c1bb90fe4f3a90e36e</a>).</div><div><br></div><div>I=E2=80=99ve tried= many different setups to avoid the problem, including different versions o= f org-mode, but the only thing that solves it is going back to emacs 28.2, = which apparently handles markers more efficiently than 29+. The only way to= solve the problem while staying in emacs 29.3 that I=E2=80=99ve found is t= o modify `counsel-outline` to not generate markers. (This solution was sugg= ested at <a href=3D"https://github.com/abo-abo/swiper/pull/1700">https://gi= thub.com/abo-abo/swiper/pull/1700</a>. The specific modifications I use can= be found at <a href=3D"https://gist.github.com/kings2u/5a8acbf0986f0848be6= 6169d2dba7260">https://gist.github.com/kings2u/5a8acbf0986f0848be66169d2dba= 7260</a>). For what it=E2=80=99s worth, I have installed emacs 29.3+ on mul= tiple different machines and observed the exact same behavior.<br></div><br= >My big 11MB org file is such an integral part of my workflow that I've= gone back to emacs 28.2 for now with the hopes that the current version of= emacs will go back to handling markers efficiently. Please let me know if = I can help further in diagnosing the problem.<br><br>Thank you for all you = do!<br><br><br>In GNU Emacs 30.0.50 (build 1, x86_64-w64-mingw32) of 2024-0= 5-25 built<br>=C2=A0on MITCHELL-16G-TO<br>Repository revision: 57dc1ed665d7= 2bc58befa4853fa479b770fe4fcc<br>Repository branch: master<br>Windowing syst= em distributor 'Microsoft Corp.', version 10.0.19045<br>System Desc= ription: Microsoft Windows 10 Home (v10.0.2009.19045.4412)<br><br>Configure= d using:<br>=C2=A0'configure --prefix=3D/c/emacs --with-modules --witho= ut-dbus<br>=C2=A0--with-native-compilation --without-compress-install --wit= h-tree-sitter<br>=C2=A0--with-mailutils --without-gconf --without-gsettings= 'CFLAGS=3D-O2<br>=C2=A0-mtune=3Dnative -march=3Dnative -fomit-frame-po= inter''<br><br>Configured features:<br>ACL GIF GMP GNUTLS HARFBUZZ = JPEG LCMS2 LIBXML2 MODULES NATIVE_COMP<br>NOTIFY W32NOTIFY PDUMPER PNG RSVG= SOUND SQLITE3 THREADS TIFF<br>TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLI= B<br><br>Important settings:<br>=C2=A0 value of $LANG: ENU<br>=C2=A0 locale= -coding-system: cp1252<br><br>Major mode: Lisp Interaction<br><br>Minor mod= es in effect:<br>=C2=A0 global-tab-line-mode: t<br>=C2=A0 tab-line-mode: t<= br>=C2=A0 override-global-mode: t<br>=C2=A0 tooltip-mode: t<br>=C2=A0 globa= l-eldoc-mode: t<br>=C2=A0 eldoc-mode: t<br>=C2=A0 show-paren-mode: t<br>=C2= =A0 electric-indent-mode: t<br>=C2=A0 mouse-wheel-mode: t<br>=C2=A0 tool-ba= r-mode: t<br>=C2=A0 menu-bar-mode: t<br>=C2=A0 file-name-shadow-mode: t<br>= =C2=A0 global-font-lock-mode: t<br>=C2=A0 font-lock-mode: t<br>=C2=A0 blink= -cursor-mode: t<br>=C2=A0 minibuffer-regexp-mode: t<br>=C2=A0 line-number-m= ode: t<br>=C2=A0 indent-tabs-mode: t<br>=C2=A0 transient-mark-mode: t<br>= =C2=A0 auto-composition-mode: t<br>=C2=A0 auto-encryption-mode: t<br>=C2=A0= auto-compression-mode: t<br>=C2=A0 abbrev-mode: t<br><br>Load-path shadows= :<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/transient-20240509.1849/transien= t hides c:/emacs/share/emacs/30.0.50/lisp/transient<br>c:/Users/Mitchell/Em= acs/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides c:/emacs/share/emac= s/30.0.50/lisp/bind-key<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-packag= e-20230426.2324/use-package hides c:/emacs/share/emacs/30.0.50/lisp/use-pac= kage/use-package<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20230= 426.2324/use-package-lint hides c:/emacs/share/emacs/30.0.50/lisp/use-packa= ge/use-package-lint<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package-20= 230426.2324/use-package-jump hides c:/emacs/share/emacs/30.0.50/lisp/use-pa= ckage/use-package-jump<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-package= -20230426.2324/use-package-ensure hides c:/emacs/share/emacs/30.0.50/lisp/u= se-package/use-package-ensure<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/use-= package-20230426.2324/use-package-diminish hides c:/emacs/share/emacs/30.0.= 50/lisp/use-package/use-package-diminish<br>c:/Users/Mitchell/Emacs/.emacs.= d/elpa/use-package-20230426.2324/use-package-delight hides c:/emacs/share/e= macs/30.0.50/lisp/use-package/use-package-delight<br>c:/Users/Mitchell/Emac= s/.emacs.d/elpa/use-package-20230426.2324/use-package-core hides c:/emacs/s= hare/emacs/30.0.50/lisp/use-package/use-package-core<br>c:/Users/Mitchell/E= macs/.emacs.d/elpa/use-package-20230426.2324/use-package-bind-key hides c:/= emacs/share/emacs/30.0.50/lisp/use-package/use-package-bind-key<br>c:/Users= /Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox hides c:/emacs/share/emacs/30.0= .50/lisp/org/ox<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-texi= nfo hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-texinfo<br>c:/Users/Mitc= hell/Emacs/.emacs.d/elpa/org-9.6.30/ox-publish hides c:/emacs/share/emacs/3= 0.0.50/lisp/org/ox-publish<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6= .30/ox-org hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-org<br>c:/Users/M= itchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-odt hides c:/emacs/share/emacs/30= .0.50/lisp/org/ox-odt<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o= x-md hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-md<br>c:/Users/Mitchell= /Emacs/.emacs.d/elpa/org-9.6.30/ox-man hides c:/emacs/share/emacs/30.0.50/l= isp/org/ox-man<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-latex= hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-latex<br>c:/Users/Mitchell/= Emacs/.emacs.d/elpa/org-9.6.30/ox-koma-letter hides c:/emacs/share/emacs/30= .0.50/lisp/org/ox-koma-letter<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-= 9.6.30/ox-icalendar hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-icalenda= r<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-html hides c:/emac= s/share/emacs/30.0.50/lisp/org/ox-html<br>c:/Users/Mitchell/Emacs/.emacs.d/= elpa/org-9.6.30/ox-beamer hides c:/emacs/share/emacs/30.0.50/lisp/org/ox-be= amer<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ox-ascii hides c:/= emacs/share/emacs/30.0.50/lisp/org/ox-ascii<br>c:/Users/Mitchell/Emacs/.ema= cs.d/elpa/org-9.6.30/org hides c:/emacs/share/emacs/30.0.50/lisp/org/org<br= >c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-version hides c:/emac= s/share/emacs/30.0.50/lisp/org/org-version<br>c:/Users/Mitchell/Emacs/.emac= s.d/elpa/org-9.6.30/org-timer hides c:/emacs/share/emacs/30.0.50/lisp/org/o= rg-timer<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-tempo hide= s c:/emacs/share/emacs/30.0.50/lisp/org/org-tempo<br>c:/Users/Mitchell/Emac= s/.emacs.d/elpa/org-9.6.30/org-table hides c:/emacs/share/emacs/30.0.50/lis= p/org/org-table<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-src= hides c:/emacs/share/emacs/30.0.50/lisp/org/org-src<br>c:/Users/Mitchell/E= macs/.emacs.d/elpa/org-9.6.30/org-refile hides c:/emacs/share/emacs/30.0.50= /lisp/org/org-refile<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/or= g-protocol hides c:/emacs/share/emacs/30.0.50/lisp/org/org-protocol<br>c:/U= sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-plot hides c:/emacs/share/= emacs/30.0.50/lisp/org/org-plot<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or= g-9.6.30/org-persist hides c:/emacs/share/emacs/30.0.50/lisp/org/org-persis= t<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-pcomplete hides c= :/emacs/share/emacs/30.0.50/lisp/org/org-pcomplete<br>c:/Users/Mitchell/Ema= cs/.emacs.d/elpa/org-9.6.30/org-num hides c:/emacs/share/emacs/30.0.50/lisp= /org/org-num<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-mouse = hides c:/emacs/share/emacs/30.0.50/lisp/org/org-mouse<br>c:/Users/Mitchell/= Emacs/.emacs.d/elpa/org-9.6.30/org-mobile hides c:/emacs/share/emacs/30.0.5= 0/lisp/org/org-mobile<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o= rg-macs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-macs<br>c:/Users/Mi= tchell/Emacs/.emacs.d/elpa/org-9.6.30/org-macro hides c:/emacs/share/emacs/= 30.0.50/lisp/org/org-macro<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6= .30/org-loaddefs hides c:/emacs/share/emacs/30.0.50/lisp/org/org-loaddefs<b= r>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-list hides c:/emacs/= share/emacs/30.0.50/lisp/org/org-list<br>c:/Users/Mitchell/Emacs/.emacs.d/e= lpa/org-9.6.30/org-lint hides c:/emacs/share/emacs/30.0.50/lisp/org/org-lin= t<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-keys hides c:/ema= cs/share/emacs/30.0.50/lisp/org/org-keys<br>c:/Users/Mitchell/Emacs/.emacs.= d/elpa/org-9.6.30/org-inlinetask hides c:/emacs/share/emacs/30.0.50/lisp/or= g/org-inlinetask<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-in= dent hides c:/emacs/share/emacs/30.0.50/lisp/org/org-indent<br>c:/Users/Mit= chell/Emacs/.emacs.d/elpa/org-9.6.30/org-id hides c:/emacs/share/emacs/30.0= .50/lisp/org/org-id<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org= -habit hides c:/emacs/share/emacs/30.0.50/lisp/org/org-habit<br>c:/Users/Mi= tchell/Emacs/.emacs.d/elpa/org-9.6.30/org-goto hides c:/emacs/share/emacs/3= 0.0.50/lisp/org/org-goto<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.3= 0/org-footnote hides c:/emacs/share/emacs/30.0.50/lisp/org/org-footnote<br>= c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-fold hides c:/emacs/sh= are/emacs/30.0.50/lisp/org/org-fold<br>c:/Users/Mitchell/Emacs/.emacs.d/elp= a/org-9.6.30/org-fold-core hides c:/emacs/share/emacs/30.0.50/lisp/org/org-= fold-core<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-feed hide= s c:/emacs/share/emacs/30.0.50/lisp/org/org-feed<br>c:/Users/Mitchell/Emacs= /.emacs.d/elpa/org-9.6.30/org-faces hides c:/emacs/share/emacs/30.0.50/lisp= /org/org-faces<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-enti= ties hides c:/emacs/share/emacs/30.0.50/lisp/org/org-entities<br>c:/Users/M= itchell/Emacs/.emacs.d/elpa/org-9.6.30/org-element hides c:/emacs/share/ema= cs/30.0.50/lisp/org/org-element<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or= g-9.6.30/org-duration hides c:/emacs/share/emacs/30.0.50/lisp/org/org-durat= ion<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-datetree hides = c:/emacs/share/emacs/30.0.50/lisp/org/org-datetree<br>c:/Users/Mitchell/Ema= cs/.emacs.d/elpa/org-9.6.30/org-cycle hides c:/emacs/share/emacs/30.0.50/li= sp/org/org-cycle<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-ct= ags hides c:/emacs/share/emacs/30.0.50/lisp/org/org-ctags<br>c:/Users/Mitch= ell/Emacs/.emacs.d/elpa/org-9.6.30/org-crypt hides c:/emacs/share/emacs/30.= 0.50/lisp/org/org-crypt<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30= /org-compat hides c:/emacs/share/emacs/30.0.50/lisp/org/org-compat<br>c:/Us= ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-colview hides c:/emacs/shar= e/emacs/30.0.50/lisp/org/org-colview<br>c:/Users/Mitchell/Emacs/.emacs.d/el= pa/org-9.6.30/org-clock hides c:/emacs/share/emacs/30.0.50/lisp/org/org-clo= ck<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-capture hides c:= /emacs/share/emacs/30.0.50/lisp/org/org-capture<br>c:/Users/Mitchell/Emacs/= .emacs.d/elpa/org-9.6.30/org-attach hides c:/emacs/share/emacs/30.0.50/lisp= /org/org-attach<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-att= ach-git hides c:/emacs/share/emacs/30.0.50/lisp/org/org-attach-git<br>c:/Us= ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/org-archive hides c:/emacs/shar= e/emacs/30.0.50/lisp/org/org-archive<br>c:/Users/Mitchell/Emacs/.emacs.d/el= pa/org-9.6.30/org-agenda hides c:/emacs/share/emacs/30.0.50/lisp/org/org-ag= enda<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol hides c:/emacs/= share/emacs/30.0.50/lisp/org/ol<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/or= g-9.6.30/ol-w3m hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-w3m<br>c:/Us= ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-rmail hides c:/emacs/share/e= macs/30.0.50/lisp/org/ol-rmail<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org= -9.6.30/ol-mhe hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-mhe<br>c:/Use= rs/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-man hides c:/emacs/share/emac= s/30.0.50/lisp/org/ol-man<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.= 30/ol-irc hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-irc<br>c:/Users/Mi= tchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-info hides c:/emacs/share/emacs/30= .0.50/lisp/org/ol-info<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/= ol-gnus hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-gnus<br>c:/Users/Mit= chell/Emacs/.emacs.d/elpa/org-9.6.30/ol-eww hides c:/emacs/share/emacs/30.0= .50/lisp/org/ol-eww<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-= eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-eshell<br>c:/Users/Mi= tchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-doi hides c:/emacs/share/emacs/30.= 0.50/lisp/org/ol-doi<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol= -docview hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-docview<br>c:/Users= /Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ol-bibtex hides c:/emacs/share/ema= cs/30.0.50/lisp/org/ol-bibtex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-= 9.6.30/ol-bbdb hides c:/emacs/share/emacs/30.0.50/lisp/org/ol-bbdb<br>c:/Us= ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc hides c:/emacs/share/emacs/3= 0.0.50/lisp/org/oc<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-n= atbib hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-natbib<br>c:/Users/Mit= chell/Emacs/.emacs.d/elpa/org-9.6.30/oc-csl hides c:/emacs/share/emacs/30.0= .50/lisp/org/oc-csl<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-= bibtex hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-bibtex<br>c:/Users/Mi= tchell/Emacs/.emacs.d/elpa/org-9.6.30/oc-biblatex hides c:/emacs/share/emac= s/30.0.50/lisp/org/oc-biblatex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org= -9.6.30/oc-basic hides c:/emacs/share/emacs/30.0.50/lisp/org/oc-basic<br>c:= /Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob hides c:/emacs/share/emac= s/30.0.50/lisp/org/ob<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/o= b-tangle hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-tangle<br>c:/Users/= Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-table hides c:/emacs/share/emacs= /30.0.50/lisp/org/ob-table<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6= .30/ob-sqlite hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sqlite<br>c:/U= sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sql hides c:/emacs/share/em= acs/30.0.50/lisp/org/ob-sql<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.= 6.30/ob-shell hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-shell<br>c:/Us= ers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-sed hides c:/emacs/share/ema= cs/30.0.50/lisp/org/ob-sed<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6= .30/ob-screen hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-screen<br>c:/U= sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-scheme hides c:/emacs/share= /emacs/30.0.50/lisp/org/ob-scheme<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/= org-9.6.30/ob-sass hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-sass<br>c= :/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ruby hides c:/emacs/shar= e/emacs/30.0.50/lisp/org/ob-ruby<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/o= rg-9.6.30/ob-ref hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ref<br>c:/U= sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-R hides c:/emacs/share/emac= s/30.0.50/lisp/org/ob-R<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30= /ob-python hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-python<br>c:/User= s/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-processing hides c:/emacs/shar= e/emacs/30.0.50/lisp/org/ob-processing<br>c:/Users/Mitchell/Emacs/.emacs.d/= elpa/org-9.6.30/ob-plantuml hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-= plantuml<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-perl hides = c:/emacs/share/emacs/30.0.50/lisp/org/ob-perl<br>c:/Users/Mitchell/Emacs/.e= macs.d/elpa/org-9.6.30/ob-org hides c:/emacs/share/emacs/30.0.50/lisp/org/o= b-org<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-octave hides c= :/emacs/share/emacs/30.0.50/lisp/org/ob-octave<br>c:/Users/Mitchell/Emacs/.= emacs.d/elpa/org-9.6.30/ob-ocaml hides c:/emacs/share/emacs/30.0.50/lisp/or= g/ob-ocaml<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-maxima hi= des c:/emacs/share/emacs/30.0.50/lisp/org/ob-maxima<br>c:/Users/Mitchell/Em= acs/.emacs.d/elpa/org-9.6.30/ob-matlab hides c:/emacs/share/emacs/30.0.50/l= isp/org/ob-matlab<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-ma= kefile hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-makefile<br>c:/Users/= Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lua hides c:/emacs/share/emacs/3= 0.0.50/lisp/org/ob-lua<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/= ob-lob hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lob<br>c:/Users/Mitch= ell/Emacs/.emacs.d/elpa/org-9.6.30/ob-lisp hides c:/emacs/share/emacs/30.0.= 50/lisp/org/ob-lisp<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-= lilypond hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-lilypond<br>c:/User= s/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-latex hides c:/emacs/share/ema= cs/30.0.50/lisp/org/ob-latex<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9= .6.30/ob-julia hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-julia<br>c:/U= sers/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-js hides c:/emacs/share/ema= cs/30.0.50/lisp/org/ob-js<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.= 30/ob-java hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-java<br>c:/Users/= Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-haskell hides c:/emacs/share/ema= cs/30.0.50/lisp/org/ob-haskell<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org= -9.6.30/ob-groovy hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-groovy<br>= c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-gnuplot hides c:/emacs/= share/emacs/30.0.50/lisp/org/ob-gnuplot<br>c:/Users/Mitchell/Emacs/.emacs.d= /elpa/org-9.6.30/ob-fortran hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-= fortran<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-forth hides = c:/emacs/share/emacs/30.0.50/lisp/org/ob-forth<br>c:/Users/Mitchell/Emacs/.= emacs.d/elpa/org-9.6.30/ob-exp hides c:/emacs/share/emacs/30.0.50/lisp/org/= ob-exp<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-eval hides c:= /emacs/share/emacs/30.0.50/lisp/org/ob-eval<br>c:/Users/Mitchell/Emacs/.ema= cs.d/elpa/org-9.6.30/ob-eshell hides c:/emacs/share/emacs/30.0.50/lisp/org/= ob-eshell<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-emacs-lisp= hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-emacs-lisp<br>c:/Users/Mitc= hell/Emacs/.emacs.d/elpa/org-9.6.30/ob-dot hides c:/emacs/share/emacs/30.0.= 50/lisp/org/ob-dot<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-d= itaa hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-ditaa<br>c:/Users/Mitch= ell/Emacs/.emacs.d/elpa/org-9.6.30/ob-css hides c:/emacs/share/emacs/30.0.5= 0/lisp/org/ob-css<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-co= re hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-core<br>c:/Users/Mitchell= /Emacs/.emacs.d/elpa/org-9.6.30/ob-comint hides c:/emacs/share/emacs/30.0.5= 0/lisp/org/ob-comint<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob= -clojure hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-clojure<br>c:/Users= /Mitchell/Emacs/.emacs.d/elpa/org-9.6.30/ob-calc hides c:/emacs/share/emacs= /30.0.50/lisp/org/ob-calc<br>c:/Users/Mitchell/Emacs/.emacs.d/elpa/org-9.6.= 30/ob-C hides c:/emacs/share/emacs/30.0.50/lisp/org/ob-C<br>c:/Users/Mitche= ll/Emacs/.emacs.d/elpa/org-9.6.30/ob-awk hides c:/emacs/share/emacs/30.0.50= /lisp/org/ob-awk<br><br>Features:<br>(shadow sort mail-extr emacsbug messag= e yank-media puny rfc822 mml<br>mml-sec epa derived gnus-util mm-decode mm-= bodies mm-encode mail-parse<br>rfc2231 mailabbrev gmm-utils mailheader send= mail rfc2047 rfc2045<br>ietf-drums mm-util mail-prsvr mail-utils org ob ob-= tangle ob-ref ob-lob<br>ob-table ob-exp org-macro org-src ob-comint org-pco= mplete pcomplete<br>org-list org-footnote org-faces org-entities time-date = noutline outline<br>ob-emacs-lisp ob-core ob-eval org-cycle org-table ol rx= org-fold<br>org-fold-core org-keys oc org-loaddefs find-func cal-menu cale= ndar<br>cal-loaddefs org-version org-compat org-macs format-spec counsel xd= g<br>xref project dired dired-loaddefs compile text-property-search comint<= br>ansi-osc ansi-color swiper ivy delsel ring ivy-faces ivy-overlay colir<b= r>color modus-vivendi-theme modus-themes cl-extra help-mode tab-line<br>use= -package use-package-ensure use-package-delight use-package-diminish<br>use= -package-bind-key bind-key use-package-core finder-inf easy-mmode epg<br>rf= c6068 epg-config gnu-elpa-keyring-update pdf-tools-autoloads<br>tablist-aut= oloads info package browse-url url url-proxy url-privacy<br>url-expand url-= methods url-history url-cookie generate-lisp-file<br>url-domsuf url-util ma= ilcap url-handlers url-parse auth-source cl-seq<br>eieio eieio-core cl-macs= password-cache json subr-x map byte-opt gv<br>bytecomp byte-compile url-va= rs cus-edit pp cus-start cus-load icons<br>wid-edit cl-loaddefs cl-lib rmc = iso-transl tooltip cconv eldoc paren<br>electric uniquify ediff-hook vc-hoo= ks lisp-float-type elisp-mode mwheel<br>dos-w32 ls-lisp disp-table term/w32= -win w32-win w32-vars term/common-win<br>tool-bar dnd fontset image regexp-= opt fringe tabulated-list replace<br>newcomment text-mode lisp-mode prog-mo= de register page tab-bar menu-bar<br>rfn-eshadow isearch easymenu timer sel= ect scroll-bar mouse jit-lock<br>font-lock syntax font-core term/tty-colors= frame minibuffer nadvice seq<br>simple cl-generic indonesian philippine ch= am georgian utf-8-lang<br>misc-lang vietnamese tibetan thai tai-viet lao ko= rean japanese eucjp-ms<br>cp51932 hebrew greek romanian slovak czech europe= an ethiopic indian<br>cyrillic chinese composite emoji-zwj charscript charp= rop case-table<br>epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-pr= eloaded button<br>loaddefs theme-loaddefs faces cus-face macroexp files win= dow<br>text-properties overlay sha1 md5 base64 format env code-pages mule<b= r>custom widget keymap hashtable-print-readable backquote threads<br>w32not= ify w32 lcms2 multi-tty move-toolbar make-network-process<br>native-compile= emacs)<br><br>Memory information:<br>((conses 16 476739 29195) (symbols 48= 26493 0)<br>=C2=A0(strings 32 133104 6737) (string-bytes 1 3784773) (vecto= rs 16 33874)<br>=C2=A0(vector-slots 8 430476 21000) (floats 8 269 15) (inte= rvals 56 554 0)<br>=C2=A0(buffers 992 12))<div><div dir=3D"ltr" class=3D"gm= ail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><br></di= v></div></div></div> --000000000000b4d60d061b376e60--
Mitchell <mitchellahren@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#71644; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.