From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71644: 30.0.50; Severe slowdown in larger files with markers beginning in emacs 29+ Date: Wed, 26 Jun 2024 14:41:06 +0300 Message-ID: <861q4k9bjh.fsf@gnu.org> References: <86ed8tozub.fsf@gnu.org> <86jzijmo5a.fsf@gnu.org> <87h6dmbyy2.fsf@localhost> <87wmmhgjao.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7099"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, mitchellahren@gmail.com, 71644@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 26 13:42:27 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sMR2g-0001eW-9r for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Jun 2024 13:42:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMR2G-0003sN-Uy; Wed, 26 Jun 2024 07:42:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sMR2F-0003s1-VL for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 07:41:59 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sMR2F-0005Ks-Ni for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 07:41:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sMR2H-0005wn-PH for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 07:42:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Jun 2024 11:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71644 X-GNU-PR-Package: emacs Original-Received: via spool by 71644-submit@debbugs.gnu.org id=B71644.171940208022800 (code B ref 71644); Wed, 26 Jun 2024 11:42:01 +0000 Original-Received: (at 71644) by debbugs.gnu.org; 26 Jun 2024 11:41:20 +0000 Original-Received: from localhost ([127.0.0.1]:38686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMR1c-0005vf-8q for submit@debbugs.gnu.org; Wed, 26 Jun 2024 07:41:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMR1a-0005vS-4P for 71644@debbugs.gnu.org; Wed, 26 Jun 2024 07:41:19 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 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==; In-Reply-To: (message from Stefan Monnier on Tue, 25 Jun 2024 16:54:44 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287930 Archived-At: > From: Stefan Monnier > Cc: Mitchell , Eli Zaretskii , > 71644@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?