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

[Lars Ingebrigtsen <larsi@gnus.org>]

Mattias Engdegård <mattiase@acm.org> writes:

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

Yeah, perhaps there's isn't a lot to be gained there, unless a lot of
the re-checking of all the arguments (etc.) (which is unnecessary once
we've ascertained that everything is, indeed, a string) can be done by
refactoring some of the underlying primitives.

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

No, probably not, since it's now done by Jansson?  So I'm closing that
one.

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

I started looking at that, and there's a huge pile of calls like

(replace-regexp-in-string ":" ";" string)

that can be rewritten to use string-replace.  But!  Every single case
requires careful analysis, exactly because replace-regexp-in-string sets
the match data.  Perhaps five lines later, there's a reference to
(match-string 0 string)?  Perhaps the reference is in the function that
called this function?

So most changes are fraught with possible unforeseen breakages, the code
is super-duper straightforward like

(setq string (replace-regexp-in-string ":" ";" string))
(setq string (replace-regexp-in-string "a" "b" string))

Then you know that you can replace the first one without any danger.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no