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

Previous Next

Full log

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

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

Eli Zaretskii <eliz <at> gnu.org> writes:

>> These patches were not proposed for inclusion in Emacs but to help Ihor solve his problems in other ways. Sorry about not making it clear.
>
> I thought you said that exposing the cache size to Lisp _was_ the way
> to better support Lisp programs that need to use huge amounts of
> regular expressions, no?  If not, how will those patches be able to
> help Ihor, given that he wants to solve them in Emacs?

Well. My original simplistic proposal was to increase REGEXP_CACHE_SIZE.
Exposing this to Elisp certainly gives more flexibility, but also has
downsides (due to linear search across the regexp cache).
Ultimately, compiled regexp objects should be much more universal and
will not require extensive benchmarking to balance between regexp
compilation and increasing regexp cache search latency. But adding a new
Elisp object type is a big deal.

For now, we should probably study what is going on in my use case more
generally and maybe figure out if some alternative approach could be
better. If a simple solution will do, it may be good enough.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Previous Next

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