Re: Performance implications of GRegex structure



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.

					- Owen

Attachment: signature.asc
Description: This is a digitally signed message part



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