WildcardMatcherHelper caching issue

[Bruno Dumon <br...@outerthought.org>]

Hi,

I noticed the new WildcardMatcherHelper class holds an internal static
map for caching. In the older solution, it was up to the caller to cache
the compiled pattern (similar to how regexp libraries work). This had
the advantage that the caller itself can decide whether the pattern
should be cached. It also avoids a potential memory leak if this code is
used to evaluate always-changing patterns, and avoids the need to do
hashmap lookups.

So I'm wondering if anyone would mind if I change it back so that caller
caches the pattern?

Thanks for any input.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: WildcardMatcherHelper caching issue

[Bruno Dumon <br...@outerthought.org>]

On Sat, 2007-01-06 at 01:03 +0100, Alfred Nathaniel wrote:
> On Fri, 2007-01-05 at 13:45 +0100, Bruno Dumon wrote:
> > Hi,
> > 
> > I noticed the new WildcardMatcherHelper class holds an internal static
> > map for caching. In the older solution, it was up to the caller to cache
> > the compiled pattern (similar to how regexp libraries work). This had
> > the advantage that the caller itself can decide whether the pattern
> > should be cached. It also avoids a potential memory leak if this code is
> > used to evaluate always-changing patterns, and avoids the need to do
> > hashmap lookups.
> > 
> > So I'm wondering if anyone would mind if I change it back so that caller
> > caches the pattern?
> > 
> > Thanks for any input.
> 
> The integrated cache is a convenience for the many client who repeated
> match the same pattern and gain performance without having to code their
> own cache management.
> 
> If you have an application where you will be matching a lot of one-shot
> patterns, you could add
> 
>    public static Map match(String pat, String str, Map cache)
> 
> which can be called with a null Map to by-pass caching.  The old
> signature then becomes simply
> 
>    public static Map match(String pat, String str) {
>        return match(pat, str, cache);
>    }
> 
> The built-in cache could also use a WeakHashMap to avoid ever-increasing
> memory consumption.

Thanks for the info.

I don't actually have an immediate use for one-shot patterns, however
I'm using the wildcard matcher and noticed the change. I thought the
compiled patterns were usually just kept in instance variables, hardly
deserving to be called "cache management", though I must admit I didn't
study how it is done everywhere. Having this cache inside the
WildcardMatcherHelper seemed like a step back to me. But if needed
non-caching behaviour can indeed be added later again while keeping the
convenience of the default cache.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: WildcardMatcherHelper caching issue

[Alfred Nathaniel <an...@apache.org>]

On Fri, 2007-01-05 at 13:45 +0100, Bruno Dumon wrote:
> Hi,
> 
> I noticed the new WildcardMatcherHelper class holds an internal static
> map for caching. In the older solution, it was up to the caller to cache
> the compiled pattern (similar to how regexp libraries work). This had
> the advantage that the caller itself can decide whether the pattern
> should be cached. It also avoids a potential memory leak if this code is
> used to evaluate always-changing patterns, and avoids the need to do
> hashmap lookups.
> 
> So I'm wondering if anyone would mind if I change it back so that caller
> caches the pattern?
> 
> Thanks for any input.

The integrated cache is a convenience for the many client who repeated
match the same pattern and gain performance without having to code their
own cache management.

If you have an application where you will be matching a lot of one-shot
patterns, you could add

   public static Map match(String pat, String str, Map cache)

which can be called with a null Map to by-pass caching.  The old
signature then becomes simply

   public static Map match(String pat, String str) {
       return match(pat, str, cache);
   }

The built-in cache could also use a WeakHashMap to avoid ever-increasing
memory consumption.

Cheers, Alfred.