Subject: Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'
From: Mattias Engdegård <[email-masked]>
To: Lars Ingebrigtsen <[email-masked]>
Cc: Dmitry Gutov <[email-masked]>, [email-masked], Stefan Kangas <[email-masked]>, Shigeru Fukaya <[email-masked]>
Date: Thu, 26 Nov 2020 14:39:01 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

26 nov. 2020 kl. 14.12 skrev Lars Ingebrigtsen <[email-masked]>:

> 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.