Re: Performance implications of GRegex structure

[Yevgen Muntyan <muntyan tamu edu>]

Yevgen Muntyan wrote:
> [snip]
> To me here the only good argument in favor of separate Match objects is 
> multi-thread uses.
> Simply because we already have Match object, just hidden. If the best 
> way to fix GRegex
> for multi-threading is a separate match object, then it should be a 
> separate match object.
>   
In fact it's not a solution, right? Since if it's separate Match
structure, then Regex still needs to keep state.
So, the solution is to rename some stuff to make GRegex be
a GRegexExp or something, and move the actual functionality
to some new GMatcher, i.e. not change anything conceptually but
explicitly separate Pattern and Matcher. Did I get it right?

Then usage would be something like

/* Compile regex for future uses */
GRegexExp *re = g_compile_pattern("foo");
GMatcher *m = g_matcher_new (re);
g_regex_exp_free(re);
...
g_matcher_find_something(m, "blah");
...
/* Finally free it when program exits */
g_matcher_free(m);

instead of current

/* Compile regex for future uses */
GRegex *re = g_regex_new("foo");
...
g_regex_match(re, "blah");
...
/* Finally free it when program exits */
g_regex_free(re);

And in multithreaded case threads would do g_matcher_new()
instead of g_regex_copy().

g_regex_copy() is weird, that's clear. API is weird, true. But
functionality right now is no different from what would be
in case of some GMatcher objects, correct?

Best regards,
Yevgen