Re: [PATCH] add compiled regexp primitive lisp object

[Augusto Stoffel]

On Wed,  7 Aug 2024 at 14:43, Helmut Eller wrote:

> On Wed, Aug 07 2024, Eli Zaretskii wrote:
>
> [...]
>> So these are two (or maybe even one) advantages, mainly in the
>> convenience area.  My counter-argument would be that the long history
>> of using the current regexps in Emacs means that these advantages are
>> relatively minor.  I'm not sure they justify adding new objects into
>> Emacs Lisp, with all its baggage.  But maybe others will disagree with
>> me.
>>
>> Are there other advantages?
>
> An advantage of regex objects is that they don't require the regexp
> cache.  The regex cache is relatively small (20 entries) and e.g. in the
> *scratch* buffer, the font lock regexps are recompiled on every
> keystroke because the cache doesn't have enough capacity.
> Interestingly, this seems to have very little performance impact.
>
> Of course, one could make the cache bigger, but for things like font
> lock, pre-compiled regexps seem like a good solution.

Ignoring the issue that regexps may be syntax-table dependent and other
complications (issues which also would need to be addressed in the
proposed approach), what would be the advantage of exposing compiled
regexp objects versus having an infinite regexp cache?

If a long-living string (e.g. a string literals appearing in
Elisp/bytecode files) is used once as a regexp, it will presumably be
used often as such; so it seems to make sense to keep the cached regexp
around forever (in the same way that one would keep the regexp object
around forever).

If a short-lived string is used as a regexp (e.g. an isearch query), one
could just as well wait and deallocate the cached regexp at the time
when the string is garbage-collected (in the same way that the compiled
regexp object would be garbage-collected at some point).

I fail to imagine a case where one would want to let the regexp object
be garbage-collected but keep the string around.