Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
XSLTProcessor
-
This component's design is intrinsically bad from a cache
perspective: the only way to access validity is through
getTransformerHandlerAndValidity which always creates the
TransformerHandler even
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
XSLTProcessor
-
This component's design is intrinsically bad from a cache
perspective: the only way to access validity is through
getTransformerHandlerAndValidity which always creates the
TransformerHandler even if we don't use it. Com
On Thursday, October 30, 2003, at 11:42 AM, Vadim Gritsenko wrote:
Jeremy Quinn wrote:
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
Let's switch it to true an ensure the transient store is really
transient.
+1. Store is checking for Serializable (again, IIRC)
Jeremy Quinn wrote:
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
Let's switch it to true an ensure the transient store is really
transient.
+1. Store is checking for Serializable (again, IIRC), which should be
enough.
We turned this on on a production box r
On Thursday, October 30, 2003, at 02:45 AM, Vadim Gritsenko wrote:
use-store
-
why in hell is use-store to false??? IIRC, it was fist set to true
because the transient store was actually not transient and tried to
serialize compiled XSLTs in the persistant store, which failed
because th
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
...
I added a "check-includes" configuration to
the TraxTransformer. If you set it to "false" imported stylesheet
are not checked for changes for the caching, but you really feel
the performance difference.
...
PS
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Due to this mechanism, each stylesheet is parsed on every request (if
cached content is used or not) which is in most cases unnecessary. As
we didn't use the "use-store" parameter of the xslt transformer this
is a real performance problem!
Is th
Nathaniel Alfred wrote:
Checking all dependencies sounds first to be the right thing to do but it can introduce a new performance bottleneck. Just think of a well structured hierarchy of stylesheets stored on a filer, where now the cache validity check requires dozens of NFS-stat calls.
Caching
rrent
implementation.
Cheers, Alfred.
>-Original Message-
>From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
>Sent: Mittwoch, 29. Oktober 2003 10:05
>To: [EMAIL PROTECTED]
>Subject: RE: [IMP] Performance problems with TraxTransformer
>
>
>Stefan Seifert wrote:
>>
Sylvain Wallez wrote
>
> You know what? I started this refactoring on my HD at the time this
> problem was raised, but never had the time to finish it...
>
> >Anyway, I agree that refactoring the XSLTProcessor is a way to
> go and that with useStore the problem is not that important.
> >
> >BUT
Sylvain Wallez wrote:
>
> Unico Hommes wrote:
>
> >
> >
> >Sylvain Wallez wrote:
> >
> >
> >>We must refactor the XSLTProcessor so that:
> >>- it returns a MultiSourceValidity if needed (see in
> o.a.c.c.source.impl in scratchpad).
> >>
> >>
> >
> >I moved it out into repository block
Unico Hommes wrote:
Sylvain Wallez wrote:
We must refactor the XSLTProcessor so that:
- it returns a MultiSourceValidity if needed (see in o.a.c.c.source.impl in scratchpad).
I moved it out into repository block in case anybody was wondering where it went. I moved it with *TraversableGen
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
While debugging/profiling a very big application for our
customer I found out that the current implementation of the
TraxTransformer is slowing down caching!
Why? Well, the caching algorithm asks every sitem
On 29.10.2003 10:09, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
-1.
If you need the optimisation quickly for your customer, please make a
different class or keep it private until we do the clean refactoring.
I already committed it before I wrote the mail because I think it'S
an important fea
Sylvain Wallez wrote:
> -1.
> If you need the optimisation quickly for your customer, please make a
> different class or keep it private until we do the clean refactoring.
>
I already committed it before I wrote the mail because I think it'S
an important feature - but I can revert it. It's not im
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >While debugging/profiling a very big application for our
> customer I found out that the current implementation of the
> TraxTransformer is slowing down caching!
> >
> >Why? Well, the caching algorithm asks every sitemap component if
> the cach
Stefan Seifert wrote:
> Wouldn't it be better to extend the validity mechanism?
> When the master xslt does not change, the includes does not change either.
> It should be possible to use an extended validity object that,
> when parsing the xslt for imports/includes is finished, stores
> the modifi
Carsten Ziegeler wrote:
While debugging/profiling a very big application for our customer I found out that the current implementation of the TraxTransformer is slowing down caching!
Why? Well, the caching algorithm asks every sitemap component if the cached content is still valid. The TraxTransfo
> Why? Well, the caching algorithm asks every sitemap
> component if the cached content is still valid. The
> TraxTransformer answers this question by looking
> if the stylesheet has changed since the last use
> (time stamp comparison).
> So far so good, but you can have imports/includes
> in you
19 matches
Mail list logo