Re: Performance implications of GRegex structure

[mark mark mielke cc]

On Fri, Mar 16, 2007 at 08:20:11AM +0100, Mathieu Lacage wrote:
> On Thu, 2007-03-15 at 10:56 -0400, Owen Taylor wrote:
> > Well, I could imagine (maybe, barely) that someone could show me numbers
> > that showed that with a variety of long and complicated regular
> > expressions, compiling them was still 10x as fast as matching them
> > against very short strings.
> > 
> > But in general, yes, part of my concern is that there are situations
> > where you are going to matching the same regular expression against
> > thousands of strings, and in that situation, unless compilation is very,
> > very, fast, the need to repeatedly recompile will inevitably produce
> > measurable overhead.
> If this were to happen, could you not just put together a per-thread
> 5-entry double hash table to cache the 5 most recently used regex
> strings ? It really seems like a no-brainer. Am I missing something ?

No. If so-required (for example, if implemented using regcomp()/regexec()),
this would be one possible way to emulate the Matcher object. It's silly,
in that GLIB-users should not need to each work their own way around it.
It's also silly, in that a PCRE-based implementation would not require
this hackery.

I already made my suggestion for emulation with libraries that don't
provide both. Pattern becomes a pool object. Matcher grabs from the pool,
or allocates for the pool, returning it to the pool on completion. Steady
state is reached. In your no-brainer example, you have assumed that there
are only 5 common RE's in use. If there were 6 that cycled, it would break.
Having each Pattern have it's own pool, allows for a minimum allocation.

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/