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#58558: 29.0.50; re-search-forward is slow in some buffers Date: Wed, 14 Dec 2022 15:32:58 +0200 Message-ID: <83v8mem7p1.fsf@gnu.org> References: <877d10r21x.fsf@localhost> <87k050nio5.fsf@localhost> <87zgdwhw0z.fsf@gnus.org> <83sfjo3tfw.fsf@gnu.org> <878rlfjmjh.fsf@localhost> <87mt9tbbbp.fsf@gnus.org> <8335bl18lo.fsf@gnu.org> <87wn8x9eqb.fsf@gnus.org> <87tu1zd2c6.fsf@localhost> <83h6xzphxm.fsf@gnu.org> <87wn6vbfaa.fsf@localhost> <838rjbpecw.fsf@gnu.org> <87fsdjwb4e.fsf@localhost> <83zgbrnv53.fsf@gnu.org> <87bko78aif.fsf@localhost> <83o7s7nqch.fsf@gnu.org> <878rjb89kq.fsf@localhost> <83mt7rnkb7.fsf@gnu.org> <87cz8musay.fsf@localhost> <831qp2nnhz.fsf@gnu.org> <87v8met8zt.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40587"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58558@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 14 16:49:51 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p5U10-000AHC-LV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Dec 2022 16:49:50 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5Rtf-0007ie-BR; Wed, 14 Dec 2022 08:34:07 -0500 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 1p5Rtb-0007hp-4j for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 08:34:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p5Rta-000384-KT for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 08:34:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5Rta-0000ag-8o for bug-gnu-emacs@gnu.org; Wed, 14 Dec 2022 08:34:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Dec 2022 13:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58558 X-GNU-PR-Package: emacs Original-Received: via spool by 58558-submit@debbugs.gnu.org id=B58558.16710247992253 (code B ref 58558); Wed, 14 Dec 2022 13:34:02 +0000 Original-Received: (at 58558) by debbugs.gnu.org; 14 Dec 2022 13:33:19 +0000 Original-Received: from localhost ([127.0.0.1]:39299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5Rst-0000aH-8D for submit@debbugs.gnu.org; Wed, 14 Dec 2022 08:33:19 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39368) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5Rso-0000a6-Er for 58558@debbugs.gnu.org; Wed, 14 Dec 2022 08:33:17 -0500 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 1p5Rsi-0002sU-1o; Wed, 14 Dec 2022 08:33:08 -0500 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=ckhgWzfFaCXiB+m+j4cnsFFxd67AOWuCkSGS3FO4T3E=; b=ALfy7hvZaz2v S6Knr866lj8KQqQGjnja0zcm2OCgwSNBX906BbH5tBogA2y+25p1lg/K5b9ofOAx1n7EyGPDEGalY r3agAEqrAke3ycevYRI3+gnA2FKLQ+WLXEd6WJJjMzR4K6Yd0cjLgzup0G19sNYoKheyGGgK7QQMq tKswjmPWV51EZd0q10GD+c75OFrk02NWOBE51cQDCt5lxDhQTytlIzHIP7Un2Ynsn3vtJL/ICDY+J l5rp2f9r52GfSbUeHd+mfjqngN+E7CmSCbENqCZRO2qzZGJg6V+MuPvn1MWwsBdmsumHJfEJJeJSZ g52K3QGQHSguYGvAFLB7+A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p5Rsb-0001E5-DM; Wed, 14 Dec 2022 08:33:02 -0500 In-Reply-To: <87v8met8zt.fsf@localhost> (message from Ihor Radchenko on Wed, 14 Dec 2022 13:23:02 +0000) 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:250962 Archived-At: > From: Ihor Radchenko > Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 58558@debbugs.gnu.org > Date: Wed, 14 Dec 2022 13:23:02 +0000 > > Eli Zaretskii writes: > > > I think I'm confused now: what do you mean by "executing the > > benchmark"? I thought the problem was that each "execution of the > > benchmark" was slower than the one before it, in which case markers > > added between benchmarks _are_ relevant. But you say they aren't? > > What did I miss? > > Increasing time of running benchmarks is just a symptom. > The real issue I am experiencing is that re-search-forward becomes > slower as I keep using Emacs. `garbage-collect' helps, but not in a long > term. > > Basically, running > > M-: (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t))) > > - right after starting Emacs is taking 3-4 seconds. > - after several hours -- 10-20 seconds > - in Emacs 28, <1 sec. > > Markers may or may not be a problem. What else could slow down buf_bytepos_to_charpos so much? All it does is examine markers. > f they are, it is not necessarily related to markers created when I > run the benchmarks. May also be some markers created during the > Emacs session. Which means massive creation of markers could be the reason, regardless of what causes such massive creation. Right? But if so, why did you say that markers created by some timer(s) were not relevant? Btw, did you try to compare the number of buffer markers in Emacs 28 and Emacs 29/30, under this scenario, when the search becomes slow enough?