Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <005101c1ee6f$b8c7ffe0$0200a8c0@GATEWAY>
From: "Dmitri Plotnikov" <dmitri@plotnix.com>
To: "Ovidiu Predescu" <ovidiu@apache.org>,
	"Ivelin Ivanov" <ivelin@apache.org>
Cc: <cocoon-dev@xml.apache.org>
References: <200204121455.g3CEt1m21890@hercules.home>
Subject: Re: [jxpath] CompiledExpression [was: New features,
 bug fixes and documentation]
Date: Sun, 28 Apr 2002 00:46:53 -0400
Organization: PLOTNIX, INC
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Ovidiu,

I have added to JXPath the explicit caching you proposed in your earlier
submission:

[... snip...]

> > >
> > > > I've got a small suggestion for an optimization, if
> > > > you don't mind. In
> > > > the implementation I have, 0.1-dev from Jakarta's
> > > > CVS, I noticed
> > > > there's no way to compile an XPath, before using it.
> > > > Having a way to
> > > > compile the XPaths to be used later, would
> > > > considerably improve the
> > > > performance in repeated operations.
> > > >
> > > > E.g. right now you have something like this:
> > > >
> > > >   Object bean = ...;
> > > >   JPathContext context =
> > > > JPathContext.newContext(bean);
> > > >   context.getValue("some XPath");
> > > >
> > > > I'd like to also have the ability to do:
> > > >
> > > >   Object bean = ...;
> > > >   JPathContext context =
> > > > JPathContext.newContext(bean);
> > > >   XPathObject xpath = new XPathObject("some XPath");
> > > >   context.getValue(xpath);
> > > >
> > > > With this approach, I can setup a dictionary of
> > > > already compiled XPath
> > > > expressions, and use compiled XPaths, instead of
> > > > having Xalan
> > > > interpret the XPath all the time.
> > > >
> > > > Last time I checked, Xalan did have the ability to
> > > > precompile XPaths
> > > > in its internal format, so maybe this is easy to
> > > > achieve.
> > > Actually JXPath is already doing something like that
> > > transparently to you. It maintains a static soft cache
> > > of parse trees (which are that internal representation
> > > you are talking about). The reason I am using soft
> > > cache as opposed to a regular map is that some
> > > applications will generate XPaths dynamically, in
> > > which case the size of the cache has a chance of going
> > > through the roof.  The soft cache is cleared by
> > > garbage collector, which removes the possibility of
> > > running out of memory.
> > >
> > > I have been thinking about improving that mechanism a
> > > little bit.  I now want to have a regular map of a
> > > limited size in addition to the soft cache.
> > > Everything that spills over the hard cache will still
> > > be stored in the soft cache.  I think that will cover
> > > the 90% case.

I now see the need for caching external to JXPath:  you may want to
precompile some expression at application start time, you may want to check
syntax before you use an expression etc.

I called "XPathObject" "CompiledExpression". You make an explicit call:
context.compile(xpath) to get a CompiledExpression.  That method will in
fact check the internal cache before it proceeds with the compilation.

Thanks again for the suggestion,

Regards,
- Dmitri


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org