Re: Performance implications of GRegex structure

[Owen Taylor <otaylor redhat com>]

On Sat, 2007-03-17 at 16:19 +0100, Marco Barisione wrote:
> Il giorno sab, 17/03/2007 alle 10.07 -0400, Matthias Clasen ha scritto:
> > Btw, one thing we might want to consider doing (regardless if we go
> > with separate pattern and matcher objects) is to make the pattern
> > optimization an optional part of the constructor rather than a
> > separate
> > function. That will ensure that the pattern is truly immutable after
> > construction. 
> 
> I prefer to keep it a separate function, what are the advantages of
> having a truly immutable GRegex? Note that the _optimize function is
> already thread-safe.

As long as it is thread safe (and it looks like it is) I don't think
there is a big advantage. Still, I would wonder why you don't have
"optimize" just as another compile flag. PCRE can't do that because
of the allocation of an extra block of memory, but that doesn't
affect GRegex.

					- Owen

P.S. - The docs could really use more specific guidance on optimize;
 I'd say something like "call optimize() (use the OPTIMIZE flag) if
 you are going to match the regular expression against large amounts
 of text. Optimization provides faster operation in that case, at the
 expense of using more memory and slightly greater compilation time."
 The current docs will make it very hard for people to know whether they
 should optimize or not. 
 
P.P.S - Though unless it actually provides a 50% or more speedup in
 matching and a 50% slowdown in compilation, I'm  not sure it's worth   
 making people decide whether optimize or not.

P.P.P.S. - I'm very glad you didn't call it _study(), since it is
 something entirely different than Perl's study() function. What was
 the PCRE author thinking with pcre_study?