Re: [PATCH] add compiled regexp primitive lisp object

[Danny McClanahan <dmcc2@hypnicjerk.ai>]

On Wednesday, August 7th, 2024 at 08:43, Helmut Eller <eller.helmut@gmail.com> wrote:

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

I'm currently running the elb-scroll benchmark along with the elp profiler to
identify hot search methods. I think it's possible to introduce a special API
for pre-compiled regexps for these calls, and I'm hoping to have a prototype of
that. Or I was, before I considered the following:


On Wednesday, August 7th, 2024 at 09:40, Augusto Stoffel <arstoffel@gmail.com> wrote:

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

Ah, it took me quite a long time to understand this, but I'm totally on
board now. I had been coming at this totally backwards, and I did not
at all realize how (as you say) the regexp string is already exactly the key we
need to use for caching. I think I like this much more than trying to introduce
a special caching API for font-lock.

Syntax table notwithstanding, I will absolutely be trying this infinite cache
approach now. This is very clever.


Thanks,
Danny