Re: Performance implications of GRegex structure



Owen Taylor wrote:
On Sat, 2007-03-17 at 16:08 -0500, Yevgen Muntyan wrote:
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?

Yes, I think you've understood what I was talking about with a
matcher object ... almost all  the methods in GRegex currently other
than g_regex_new()/g_regex_optimize() are conceptually matcher methods.

I don't have any objection to a matcher object with state; what I don't
like is binding it together with the pattern into a single indivisible
object.
What I was arguing to (if you ignore "don't change it period" part)
was creating new match objects every time you perform a match
(it's what's done in Python). Basically I don't want every match()
method to get me new allocated structure which has to be freed.
And given it wouldn't work anyway, I was arguing to something
which wouldn't work anyway :)
Making cool new API which would be nice is certainly not a bad
thing.

One thing should be taken care of: how all those things will
be copied/referenced. The language bindings concern led
to this silly g_regex_copy(); so we can get same funny
thing when someone says "not bindings-friendly" about
new API.
Perhaps making Matcher and Regex ref-countable (perhaps
internally for Regex) wouldn't be bad, would it?

It would be great if concerned people [1] commented  about it in
http://bugzilla.gnome.org/show_bug.cgi?id=419368

Yevgen

[1] Owen :)




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]