GNU bug report logs - #63225
Compiling regexp patterns (and REGEXP_CACHE_SIZE in search.c)

Previous Next

Full log

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 63225 <at> debbugs.gnu.org
Subject: Re: bug#63225: Compiling regexp patterns (and REGEXP_CACHE_SIZE in
 search.c)
Date: Tue, 9 May 2023 17:05:47 +0200

9 maj 2023 kl. 14.02 skrev Ihor Radchenko <yantar92 <at> posteo.net>:

> - forward-line + skip-chars-forward      :: (2.980 2 0.648)
> - beginning-of-line + looking-at-p       :: (7.189 2 0.653)
> - beginning-of-line + skip-chars-forward :: (6.833 2 0.634)
> - forward-line + looking-at-p            :: (3.180 2 0.663)

Thanks for measuring. (The regexp cache usage is a secondary cost to looking-at-p that isn't covered by your benchmark.)

You may want to try the small improvement to skip-chars-forward that just arrived on master.

> Will it make sense to use a combination of char-after and
> skip-chars-forward every single time?

Maybe, depending on how complex that combination would be. Applications under regexp cache pressure (like Org) may gain more from it, but of course it's also a question of programming convenience.

> May you elaborate what is the blocker then?

Mostly time, but also coming up with a design that is compatible and reasonably future-safe, and convincing people that it's a good way forward (assuming it actually is). Emacs is a collaborative effort, after all.

Previous Next

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