Re: regex caching

Hi Eric!

On 9 Oct 2007, at 17:50, Eric Blake wrote:
> 2007-10-09  Eric Blake  <[email protected]>
>
> 	Fix regexp regression of 2007-09-29.
> 	* src/builtin.c (substitute): Allow NULL regs when no
> 	subexpressions were present.
> 	(m4_regexp): Handle \ escapes even with empty regex.
> 	* doc/m4.texinfo (Regexp, Patsubst): Catch this bug.
>
> 	Cache regex compilation for another autoconf speedup.
> 	* src/m4.h (free_macro_sequence): Rename...
> 	(free_regex): ...to this.
> 	* src/m4.c (main): Update caller.
> 	* src/builtin.c (REGEX_CACHE_SIZE, m4_regex, regex_cache): New
> 	declarations.
> 	(compile_pattern): New function; cache recent regexes.
> 	(free_regex): Rename, and clean up additional memory.
> 	(m4_regexp, m4_patsubst): Use new function.

Nice work!

As food for thought, I wonder whether we can make this work even  
better by
implementing a least-frequently-used or least-recently-used queue of  
cached
values, so that m4 is more likely to retain the cached values that  
will be
more likely to be reused in the future?

I agree that a tunable parameter is worthwhile too.  And that, in  
turn, had
me thinking that (since I want to have the next major release be fully
introspective) we should devote some effort to coming up with a clean  
and
minimally intrusive way to access and change all the various  
parameters we
want to access from command line options and macros.  The main thing I'm
keen to avoid is adding a whole new command-line option and a brand new
macro every time we think of a new parameter to introspect...

As a starter, how about adding a future proof `-o' option that takes  
a comma
separated list of `option' or `nooption' or `option=value'  
parameters, along
with an m4option macro that either expands to the list of all valid  
current
option settings when invoked without arguments, or parses an m4 comma- 
list of
options in the same format as the `-o' command line?  Inside the  
code, we
can certainly take this opportunity to clean up the m4 context  
structure to
store the values in a single hash table.

Of course there is nothing to stop us continuing to support existing  
options,
or even adding new ones if we feel like it, but I think it would be a  
boon
to also provide a unified introspective interface that makes it  
really easy
for us to quickly add tunable parameters to m4 -- such as  
REGEX_CACHE_SIZE.

Cheers,
	Gary
-- 
   ())_.              Email me: [email protected]
   ( '/           Read my blog: http://blog.azazil.net
   / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_ Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

_______________________________________________
M4-patches mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/m4-patches