On Thu, 9 Oct 2003, Sylvain Wallez wrote:
> Stephan Michels wrote:
>
> >On Tue, 7 Oct 2003, Sylvain Wallez wrote:
> >>AFAIU, the use of JXTemplate as a generator allows the template to be
> >>pre-analyzed and stored into the cache, thus allowing a greater
> >>performance. This cannot be achieved with the transformer.
> >>
> >>There are use cases where templates are dynamically computed. In these
> >>cases, you can either use the JXTemplate transformer or use the
> >>generator with a cocoon: source. In that latter case, you also benefit
> >>of the fact that the cocoon: source may be cached as well.
> >>
> >>
> >
> >Yes, but the problem is that the output of the JXTemplate is high
> >dynamic, and isn't cachable, so I make most of transformations before
> >like i18n and some other.
> >
>
> That's why I was suggesting to use a "cocoon:" source as the input of
> JXTemplateGenerator: this allows the template to be cached. The other
> solution is to use CachingPointPipeline.
Hmm, yes will be a solution, but like the following case more
<map:generate type="file">
<map:transform type="i18n">
<map:transform type="xsl" src="..">
<map:transform type="xsl" src="..">
<map:transform type="jx">
<map:transform type="xsl" src="..">
<map:serialze>
instead of
<map:generate type="file">
<map:transform type="i18n">
<map:transform type="xsl" src="..">
<map:transform type="xsl" src="..">
<map:serialze type="xml">
<map:generate type="jx" src="cocoon:/whatever">
<map:transform type="xsl" src="..">
<map:serialze>
> >There is also some other thing, the newest jvm are optimized to dispatch
> >great numbers of small classes, like the classes, which be used to store
> >the events.
> >
>
> Sorry, what do you mean by "dispatch great number of small classes" ? Is
> it that about the handling of small short-lived objects ?
Yes, so caching these event classes gives more problems than benefits.
That why sometimes pool of objects are slower than the instantiation.
But just a thought, Stephan.
