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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: mattiase <at> acm.org, larsi <at> gnus.org, 44861 <at> debbugs.gnu.org,
 shigeru.fukaya <at> gmail.com
Subject: Re: bug#44861: 27.1; [PATCH] signal in `replace-regexp-in-string'
Date: Thu, 26 Nov 2020 16:41:32 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 26 Nov 2020 05:43:29 -0800
> Cc: 44861 <at> debbugs.gnu.org, Shigeru Fukaya <shigeru.fukaya <at> gmail.com>
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > But I wonder -- would it make sense to move the entire
> > replace-regexp-in-string function to C?
> 
> Before we undertake any major changes in that direction, perhaps we
> should benchmark the relevant functions on the native-comp branch?  It
> changes the benchmarks by quite a lot in some cases.

Benchmarking is always welcome, but I don't think we should dismiss
performance improvements by assuming everyone will use the
natively-compiled Lisp code VSN.  I'm quite sure *.elc files will be
used in the observable future by many people.  I also expect C code to
run faster than natively-compiled Lisp, when significant
implementation changes, such as those suggested by Mattias, are
involved.

Previous Next

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