Re: Performance implications of GRegex structure

[mark mark mielke cc]

On Fri, Mar 16, 2007 at 09:15:37PM -0500, Yevgen Muntyan wrote:
> 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").

It looks to me like you are suggesting the worst of all worlds.
Not thread-safe, not scaleable, and not simple.

If you want simple - give up on GRegexp altogether. Try something like:

    if (g_string_regexp_match(s, pattern))
        ...

If it happens to do some sort of internal caching - great. If not?
At least it is simple. For Java, this maps to:

    if (string.matches(pattern))
        ...

Having a matcher object serves more purposes than just thread
scaleability. What if I wish to walk through the string, finding
each match, processing each match as it is found? Why should I
have to search the entire search before I can display the first
match?

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.

Cheers,
mark

-- 
mark mielke cc / markm ncf ca / markm nortel com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada

  One ring to rule them all, one ring to find them, one ring to bring them all
                       and in the darkness bind them...

                           http://mark.mielke.cc/