Re: Performance implications of GRegex structure

[Yevgen Muntyan <muntyan tamu edu>]

Matthias Clasen wrote:
> On 3/16/07, Marco Barisione <marco barisione org> wrote:
>
>   
> > BTW if you want I can split GRegex in two separate objects.
> >     
>
> Since that seems to be the overwhelming preference,
"overwhelming"?
>  that might
> be a good idea. I hope this shouldn't be too bad, since GRegex
> is already split into pattern and match objects, internally.
>   
Exactly, internally. Compare

return g_regex_match(re, "foobar", 0, 0);

and

Match *m;
gboolean result;
m = g_regex_match(re, "foobar", 0, 0);
result = m != NULL;
g_regex_match_free(m);
return result;

I do understand that a separate match object is a good idea.
But "separate match object in C API is a good idea" is questionable.
While thread-safety is important, it doesn't sound feasible a single
GRegex object will be used from different threads to match something
in *many* cases. Maybe it makes sense to add thread safety
in some other way? The single-object version is certainly more
convenient than a version with a separate match object.
By the way, I don't know about Java, but having re.match()
return an object is very often gets in your way in Python (for
different reasons but it does say something about "it's done
so in Python").

Best regards,
Yevgen