GNU bug report logs - #44861
27.1; [PATCH] signal in `replace-regexp-in-string'

Previous Next

Package: emacs;

Reported by: Shigeru Fukaya <shigeru.fukaya <at> gmail.com>

Date: Wed, 25 Nov 2020 04:03:02 UTC

Severity: normal

Tags: confirmed, patch

Merged with 15107

Found in versions 24.3, 25.1, 27.1

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

Full log

Message #27 received at 44861-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 44861-done <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>,
 Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
Subject: Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'
Date: Thu, 26 Nov 2020 14:39:01 +0100

26 nov. 2020 kl. 14.12 skrev Lars Ingebrigtsen <larsi <at> gnus.org>:

> I'm all for speeding up replace-regexp-in-string (which is used all over
> the place), so your change looks reasonable to me.

Thank you! Pushed to master.

> But I wonder -- would it make sense to move the entire
> replace-regexp-in-string function to C?

Probably, but that would be a pure performance improvement. Most of the time is currently consumed in primitives (string-match, replace-match, substring, concat) so don't expect huge savings unless a substantially different approach is taken.

(Dmitry Gutov asked for a C implementation in bug#20273 for improving the speed of json encoding; is that still relevant?)

A bigger saving yet would be to use the much faster string-replace wherever possible. A little sweeping refactoring project perhaps? It would also improve readability -- no regexp quoting, fewer mysterious arguments like LITERAL and FIXEDCASE to worry about, etc.
This bug report was last modified 4 years and 169 days ago.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.