Re: Performance implications of GRegex structure

["Matthias Clasen" <matthias clasen gmail com>]

On 3/17/07, Yevgen Muntyan <muntyan tamu edu> wrote:

> >  Why should I
> > have to search the entire search before I can display the first
> > match?
> >
> You can't do the contrary - find all matches and display them.
> (I guess Marco should know better, I've never done stuff like
> this)
> > In Perl, this functionality is available as:
> >
> >     while ($scalar =~ /(pattern)/g) {
> >         ... each match ...
> >     }
> >
> > With a Matcher object, the same can be accomplished in a thread-safe
> > manner.
> >
> Could you show how it would be done (i.e. show C code)?

With GRegex  you call g_regex_match_next() until it returns FALSE to
find all nonoverlapping matches.

Since a GRegex is a combination of pattern+matcher, it is not too surprising
that you can do all the things that you can do with a separate matcher
with a GRegex, too.

I can certainly appreciate the arguments of both sides here:

pro single object: makes for simpler application code in simple cases

contra single object: complicated semantics of g_regex_copy() and a
somewhat unnatural pattern for sharing between threads.

Personally, I'd tend towards giving the contra arguments more weight,
since in many of the simple cases you can probably either get away
with something like g_regex_match_simple() (which saves you dealing
with the single GRegex object, too), or you can write your own similar
wrapper that handles the match object for you.

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.

Matthias