Re: Performance implications of GRegex structure
- From: Owen Taylor <otaylor redhat com>
- To: Marco Barisione <marco www barisione org>
- Cc: GTK Devel <gtk-devel-list gnome org>
- Subject: Re: Performance implications of GRegex structure
- Date: Sat, 17 Mar 2007 11:44:35 -0400
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
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?
] [Thread Prev