cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <>
Subject Re: WildcardMatcherHelper caching issue
Date Sun, 07 Jan 2007 12:24:10 GMT
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                   
Outerthought - Open Source, Java & XML Competence Support Center                

View raw message