From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#58558: 29.0.50; re-search-forward is slow in some buffers Date: Tue, 13 Dec 2022 18:40:17 +0000 Message-ID: <875yef87vy.fsf@localhost> References: <877d10r21x.fsf@localhost> <87ilkk6ri5.fsf@localhost> <87v8okjei9.fsf@gnus.org> <87tu44jdce.fsf@localhost> <87czasjd9j.fsf@gnus.org> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34972"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 58558@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 13 19:41:30 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 1p5ADZ-0008sw-28 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 13 Dec 2022 19:41:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5ADD-0007NC-Pf; Tue, 13 Dec 2022 13:41: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 1p5AD9-0007MX-Ar for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 13:41: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 1p5AD9-0007lj-0v for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 13:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5AD8-0003kB-S5 for bug-gnu-emacs@gnu.org; Tue, 13 Dec 2022 13:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Dec 2022 18:41: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.167095683314350 (code B ref 58558); Tue, 13 Dec 2022 18:41:02 +0000 Original-Received: (at 58558) by debbugs.gnu.org; 13 Dec 2022 18:40:33 +0000 Original-Received: from localhost ([127.0.0.1]:33947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5ACe-0003jO-Qk for submit@debbugs.gnu.org; Tue, 13 Dec 2022 13:40:33 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:43141) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5ACc-0003jI-DZ for 58558@debbugs.gnu.org; Tue, 13 Dec 2022 13:40:31 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 47810240103 for <58558@debbugs.gnu.org>; Tue, 13 Dec 2022 19:40:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1670956824; bh=2XWdsOVIGMW1J+rsD+t5LEyT1DOHct44/be7ioukd9Q=; h=From:To:Cc:Subject:Date:From; b=UlNSm495CzyNlBwBZ7DswywOkCwdI5zAA5JcZbIwqSUZYnNyX2L9OA7w2eoYiBluB OM+i/CACjUjDAFlfWRYXWIDohsZHZjH9Xk4daj/pHtBwlT+jRpKQO/81oh0B2vWi5r NZLE4Zt+l/aUXxGVC5K5+DfaelwDGVesT6iv/+M/vIGb7guStH7/BPj2I1sYvgMBQo SIp9SeMRlt9seHlCHDED3vW0EpG6mt9xFZ4k6T48n7MjKvcK0A2HlkFUoxCn++iZsr ahe2fyaCH50Rd1fE0cQx369TJYSf/VdntlDtfcLl/iMnRZpbhlXQISkG4B9fYKG4vp 74kA1lr9Ezgcg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NWnP2462Jz6tqC; Tue, 13 Dec 2022 19:40:22 +0100 (CET) In-Reply-To: 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:250880 Archived-At: Stefan Monnier writes: >> The benchmark itself does not trigger the breakpoint. > > Does that mean that `Fmatch_data` is not called during a single > `re-search-forward` (not a surprise: you'd need to put a breakpoint on > `build_marker` to see the markers built by `buf_bytepos_to_charpos`) > but is called between `re-search-forward`, or that it's not called at > all during the whole benchmark where you perform several > `re-search-forward` which grow progressively slower? I do the benchmark via M-: (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t))) The breakpoint triggers after the minibuffer outputs the elapsed time. During redisplay, AFAIU. > If it's the latter, then those calls can't explain the slowdown, right? The slowdown manifests by increasing elapsed time upon subsequent benchmark calls like the above. So, redisplay may or may not be a part of it. I tried to run (progn (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t))) (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t)))) 4 times: Elapsed time: 16.399824s Elapsed time: 17.009694s nil Elapsed time: 18.187187s Elapsed time: 18.597610s nil Elapsed time: 18.851388s Elapsed time: 19.593968s nil Elapsed time: 20.194616s Elapsed time: 20.414686s nil Though message may still trigger the redisplay. Not sure if this small test really reveals anything useful. Now, with (garbage-collect): (progn (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t))) (garbage-collect) (benchmark-progn (goto-char (point-min)) (while (re-search-forward yant/re nil t)))) Elapsed time: 20.576637s Elapsed time: 15.734101s Elapsed time: 16.101646s Elapsed time: 16.179796s Elapsed time: 16.545040s Elapsed time: 16.365847s Elapsed time: 16.842143s Elapsed time: 16.726615s So, GC does help somewhat. Then, if I kill and re-open the Org buffer: Elapsed time: 72.847256s ;; <- Org just did a bunch of re-search for initial folding and setup Elapsed time: 4.864642s re-open again, but GC before running the benchmark: Elapsed time: 4.884221s Elapsed time: 4.368755s >> If I read the backtrace correctly, something in my custom mode-line is >> triggering Fmatch_data that creates markers. > > The most common calls to `match-data` are from `save-match-data`. > And most uses of `save-match-data` are ill-advised (as the docstring > explains `save-match-data' should be used to save *your* match data > rather than your caller's match data), so you might like to double check > whether that call to `match-data` can be eliminated altogether. This is coming from s.el. In any case, this implementation detail did not change as I switched from Emacs 28 to Emacs 29. It is Emacs doing something less efficiently here. What I can try to do is replacing s-* functions in my mode-line with built-ins. Will it help debugging this issue? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at