You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ma...@rzb.at on 2003/09/24 15:51:33 UTC
setup method inside transformers, Performance?
Hi,
does anybody have any idea why calling the setup method for some
transformers (like the stylesheet transfomer) takes up to 200 milliseconds?
The execution of the transformer is comparably fast (60 ms), but we get a
performance problem when we chain stylesheet transfomers which need 200 ms
each for the setup.
Any help would be appreciated!
cheers
Manfred
Re: setup method inside transformers, Performance?
Posted by Vadim Gritsenko <va...@verizon.net>.
Geoff Howard wrote:
> Vadim Gritsenko wrote:
>
>> Jeremy Quinn wrote:
>>
>>>
>>> On Wednesday, September 24, 2003, at 04:33 PM, Vadim Gritsenko wrote:
>>>
>>>> Bruno Dumon wrote:
>>>>
...
>>>>> Set the use-store parameter in the cocoon.xconf to true, to enable
>>>>> caching of compiled stylesheets. It is false by default.
>>>>
>>>>
>>>> Is there still a reason why it set to false? It's true in Cocoon
>>>> 2.0... And I bet you can't get into production with 2.1 without
>>>> enabling it...
>>>
>>>
>>> Surely this setting means that XSLT will not reload-on-change,
>>> unless cocoon is restarted?
>>
>>
>> No, that's not true. It will reload. Why it would not, it always did
>> a reload on change? But it will cache compiled stylesheets in a
>> transient store.
>
>
> But won't that transient store automatically get written out to
> persistent store on shutdown (if it's configured with persistent
> store, which it is by default)?
Stylesheets are not serializable :)
Vadim
Re: setup method inside transformers, Performance?
Posted by Geoff Howard <co...@leverageweb.com>.
Vadim Gritsenko wrote:
> Jeremy Quinn wrote:
>
>>
>> On Wednesday, September 24, 2003, at 04:33 PM, Vadim Gritsenko wrote:
>>
>>> Bruno Dumon wrote:
>>>
>>>> On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> does anybody have any idea why calling the setup method for some
>>>>> transformers (like the stylesheet transfomer) takes up to 200
>>>>> milliseconds?
>>>>> The execution of the transformer is comparably fast (60 ms), but we
>>>>> get a
>>>>> performance problem when we chain stylesheet transfomers which need
>>>>> 200 ms
>>>>> each for the setup.
>>>>>
>>>>> Any help would be appreciated!
>>>>>
>>>>
>>>> Set the use-store parameter in the cocoon.xconf to true, to enable
>>>> caching of compiled stylesheets. It is false by default.
>>>>
>>>
>>> Is there still a reason why it set to false? It's true in Cocoon
>>> 2.0... And I bet you can't get into production with 2.1 without
>>> enabling it...
>>
>> Surely this setting means that XSLT will not reload-on-change, unless
>> cocoon is restarted?
>
> No, that's not true. It will reload. Why it would not, it always did a
> reload on change? But it will cache compiled stylesheets in a transient
> store.
But won't that transient store automatically get written out to
persistent store on shutdown (if it's configured with persistent store,
which it is by default)?
Geoff
Re: setup method inside transformers, Performance?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, September 25, 2003, at 01:21 PM, Vadim Gritsenko wrote:
> Jeremy Quinn wrote:
>
>>
>> On Wednesday, September 24, 2003, at 04:33 PM, Vadim Gritsenko wrote:
>>
>>> Bruno Dumon wrote:
>>>
>>>> On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> does anybody have any idea why calling the setup method for some
>>>>> transformers (like the stylesheet transfomer) takes up to 200
>>>>> milliseconds?
>>>>> The execution of the transformer is comparably fast (60 ms), but
>>>>> we get a
>>>>> performance problem when we chain stylesheet transfomers which
>>>>> need 200 ms
>>>>> each for the setup.
>>>>>
>>>>> Any help would be appreciated!
>>>>>
>>>>
>>>> Set the use-store parameter in the cocoon.xconf to true, to enable
>>>> caching of compiled stylesheets. It is false by default.
>>>>
>>>
>>> Is there still a reason why it set to false? It's true in Cocoon
>>> 2.0... And I bet you can't get into production with 2.1 without
>>> enabling it...
>>
>>
>> Surely this setting means that XSLT will not reload-on-change, unless
>> cocoon is restarted?
>
>
> No, that's not true. It will reload. Why it would not, it always did a
> reload on change? But it will cache compiled stylesheets in a
> transient store.
Thanks (as ever) for your clarification, Vadim.
regards Jeremy
RE : RE : SAX ElementFilter Transformer
Posted by Rasik Pandey <ra...@ajlsm.com>.
Hello,
>I am just curious, why couldn't this be done using an XALT
You are right it could be easily down in that fashion, but we do it in
SAX for better performance.
Rasik
>transformer ?
>
>
>At 09:35 AM 9/25/2003, Rasik Pandey wrote:
>>Salut,
>>
>> >I'm interested :=)
>> >
>> >I was planning to make one actually.
>> >
>> >Could you tell me more about it please?
>>
>>Vous êtes où en l'hexagone?
>>
>>Here is some quick commentary, let me know if it isn't clear!
>>
>><!--transformer for filtering elements as sax events
>>The parameter names are a list of :
>>a)element names (qualified or unqualified
>>b)namespace uris of elements unwanted
>> (this will also remove the startPrefixMapping and
>>endPrefixMapping events for the uri) c)namespace prefixes of
>elements
>>unwanted (this will also remove the startPrefixMapping and
>>endPrefixMapping events for the uri)
>>d)simple downward traversal xpath not referecing
>attributes(but maybe in
>>the future)
>>
>>The values can either be empty strings or the exact namespace uri of
>>the element. for which the sax events will be stripped or kept
>>depending on the "send" parameter, the "send" parameter default is
>>"false" meaning strip the elements specified as parameters.
>>
>>Transformer definition in sitemap:
>>
>><map:transformer name="elemFilter"
>>src="fr.gouv.culture.sdx.sitemap.transformers.ElementFilter"
>>logger="sitemap.transformer.elemFilt">
>>
>>internal parameter indicating whether to send elements in
>the parameter
>>list or not (this parmeter name (send) should be prefixed
>(blah:send)
>>in the future to avoid any confusions with element names) :
>>
>><parameter name="send" value="true | false"/>
>>
>>example params :
>>
>><parameter name="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"
>>value=""/>
>><parameter
>>name="/sdx:document/sdx:results/sdx:result/record/metadata/pa
>:unite_doc
>>u
>>mentaire" value=""/>
>><parameter name="pa:unite_documentaire"
>>value="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"/>
>>
>></map:transformer>
>>
>>Using it in a pipeline:
>>
>><map:match ...>
>> ...
>> <map:transform type="elemFilter"/>
>>
>> OR
>> <map:transform type="elemFilter">
>> <map:parameter name="send" value="true |
>>false"/>
>> other element name params
>> </map:transform>
>> ...
>></map:match ...>
>>
>>
>>-->
>>
>>
>>Rasik
>
RE : SAX ElementFilter Transformer
Posted by Oleg Dulin <ol...@opence.net>.
I am just curious, why couldn't this be done using an XALT transformer ?
At 09:35 AM 9/25/2003, Rasik Pandey wrote:
>Salut,
>
> >I'm interested :=)
> >
> >I was planning to make one actually.
> >
> >Could you tell me more about it please?
>
>Vous êtes où en l'hexagone?
>
>Here is some quick commentary, let me know if it isn't clear!
>
><!--transformer for filtering elements as sax events
>The parameter names are a list of :
>a)element names (qualified or unqualified
>b)namespace uris of elements unwanted
> (this will also remove the startPrefixMapping and
>endPrefixMapping events for the uri)
>c)namespace prefixes of elements unwanted
>(this will also remove the startPrefixMapping and endPrefixMapping
>events for the uri)
>d)simple downward traversal xpath not referecing attributes(but maybe in
>the future)
>
>The values can either be empty strings or the exact namespace uri of the
>element. for which the sax events will be stripped or kept depending on
>the "send" parameter, the "send" parameter default is "false" meaning
>strip the elements specified as parameters.
>
>Transformer definition in sitemap:
>
><map:transformer name="elemFilter"
>src="fr.gouv.culture.sdx.sitemap.transformers.ElementFilter"
>logger="sitemap.transformer.elemFilt">
>
>internal parameter indicating whether to send elements in the parameter
>list or not
>(this parmeter name (send) should be prefixed (blah:send) in the future
>to avoid any confusions with element names) :
>
><parameter name="send" value="true | false"/>
>
>example params :
>
><parameter name="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"
>value=""/>
><parameter
>name="/sdx:document/sdx:results/sdx:result/record/metadata/pa:unite_docu
>mentaire" value=""/>
><parameter name="pa:unite_documentaire"
>value="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"/>
>
></map:transformer>
>
>Using it in a pipeline:
>
><map:match ...>
> ...
> <map:transform type="elemFilter"/>
>
> OR
> <map:transform type="elemFilter">
> <map:parameter name="send" value="true |
>false"/>
> other element name params
> </map:transform>
> ...
></map:match ...>
>
>
>-->
>
>
>Rasik
RE : SAX ElementFilter Transformer
Posted by Rasik Pandey <ra...@ajlsm.com>.
Salut,
>I'm interested :=)
>
>I was planning to make one actually.
>
>Could you tell me more about it please?
Vous êtes où en l'hexagone?
Here is some quick commentary, let me know if it isn't clear!
<!--transformer for filtering elements as sax events
The parameter names are a list of :
a)element names (qualified or unqualified
b)namespace uris of elements unwanted
(this will also remove the startPrefixMapping and
endPrefixMapping events for the uri)
c)namespace prefixes of elements unwanted
(this will also remove the startPrefixMapping and endPrefixMapping
events for the uri)
d)simple downward traversal xpath not referecing attributes(but maybe in
the future)
The values can either be empty strings or the exact namespace uri of the
element. for which the sax events will be stripped or kept depending on
the "send" parameter, the "send" parameter default is "false" meaning
strip the elements specified as parameters.
Transformer definition in sitemap:
<map:transformer name="elemFilter"
src="fr.gouv.culture.sdx.sitemap.transformers.ElementFilter"
logger="sitemap.transformer.elemFilt">
internal parameter indicating whether to send elements in the parameter
list or not
(this parmeter name (send) should be prefixed (blah:send) in the future
to avoid any confusions with element names) :
<parameter name="send" value="true | false"/>
example params :
<parameter name="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"
value=""/>
<parameter
name="/sdx:document/sdx:results/sdx:result/record/metadata/pa:unite_docu
mentaire" value=""/>
<parameter name="pa:unite_documentaire"
value="http://bnsa.aquitaine.fr/ap/format-pivot/1.0"/>
</map:transformer>
Using it in a pipeline:
<map:match ...>
...
<map:transform type="elemFilter"/>
OR
<map:transform type="elemFilter">
<map:parameter name="send" value="true |
false"/>
other element name params
</map:transform>
...
</map:match ...>
-->
Rasik
RE: SAX ElementFilter Transformer
Posted by Nicolas Toper <nt...@jouve.fr>.
Hi,
I'm interested :=)
I was planning to make one actually.
Could you tell me more about it please?
-----Message d'origine-----
De : Rasik Pandey [mailto:rasik.pandey@ajlsm.com]
Envoye : jeudi 25 septembre 2003 14:26
A : dev@cocoon.apache.org
Objet : SAX ElementFilter Transformer
Hello All,
I have written a simple element filter, an XMLPipe which can strip
elements from a SAX stream based upon a list of parameters (element
names, etc). It has two modes, the first being to strip the elements in
the list from the SAX stream, and the second being to only pass the
elements in the list on to the XMLConsumer. We are currently using it
as a sitemap Transformer. If there is any interest in this for Cocoon,
please let me know.
Regards,
Rasik Pandey
SAX ElementFilter Transformer
Posted by Rasik Pandey <ra...@ajlsm.com>.
Hello All,
I have written a simple element filter, an XMLPipe which can strip
elements from a SAX stream based upon a list of parameters (element
names, etc). It has two modes, the first being to strip the elements in
the list from the SAX stream, and the second being to only pass the
elements in the list on to the XMLConsumer. We are currently using it
as a sitemap Transformer. If there is any interest in this for Cocoon,
please let me know.
Regards,
Rasik Pandey
Re: setup method inside transformers, Performance?
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeremy Quinn wrote:
>
> On Wednesday, September 24, 2003, at 04:33 PM, Vadim Gritsenko wrote:
>
>> Bruno Dumon wrote:
>>
>>> On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
>>>
>>>> Hi,
>>>>
>>>> does anybody have any idea why calling the setup method for some
>>>> transformers (like the stylesheet transfomer) takes up to 200
>>>> milliseconds?
>>>> The execution of the transformer is comparably fast (60 ms), but we
>>>> get a
>>>> performance problem when we chain stylesheet transfomers which need
>>>> 200 ms
>>>> each for the setup.
>>>>
>>>> Any help would be appreciated!
>>>>
>>>
>>> Set the use-store parameter in the cocoon.xconf to true, to enable
>>> caching of compiled stylesheets. It is false by default.
>>>
>>
>> Is there still a reason why it set to false? It's true in Cocoon
>> 2.0... And I bet you can't get into production with 2.1 without
>> enabling it...
>
>
> Surely this setting means that XSLT will not reload-on-change, unless
> cocoon is restarted?
No, that's not true. It will reload. Why it would not, it always did a
reload on change? But it will cache compiled stylesheets in a transient
store.
Vadim
Re: setup method inside transformers, Performance?
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Wednesday, September 24, 2003, at 04:33 PM, Vadim Gritsenko wrote:
> Bruno Dumon wrote:
>
>> On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
>>
>>> Hi,
>>>
>>> does anybody have any idea why calling the setup method for some
>>> transformers (like the stylesheet transfomer) takes up to 200
>>> milliseconds?
>>> The execution of the transformer is comparably fast (60 ms), but we
>>> get a
>>> performance problem when we chain stylesheet transfomers which need
>>> 200 ms
>>> each for the setup.
>>>
>>> Any help would be appreciated!
>>>
>>
>> Set the use-store parameter in the cocoon.xconf to true, to enable
>> caching of compiled stylesheets. It is false by default.
>>
>
> Is there still a reason why it set to false? It's true in Cocoon
> 2.0... And I bet you can't get into production with 2.1 without
> enabling it...
Surely this setting means that XSLT will not reload-on-change, unless
cocoon is restarted?
So it would depend on whether we are releasing a build ideal for
setting up a production server, or one ideal for setting up a
development server.
It would be nice to put together a list of recommended modifications to
cocoon.xconf for converting from a development to a production server :)
Or alternatively, release a dev-cocoon.xconf and a prod-cocoon.xconf.
Thanks for the tip anyway, this is one I missed!!
regards Jeremy
Re: setup method inside transformers, Performance?
Posted by Vadim Gritsenko <va...@verizon.net>.
Bruno Dumon wrote:
>On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
>
>
>>Hi,
>>
>>does anybody have any idea why calling the setup method for some
>>transformers (like the stylesheet transfomer) takes up to 200 milliseconds?
>>The execution of the transformer is comparably fast (60 ms), but we get a
>>performance problem when we chain stylesheet transfomers which need 200 ms
>>each for the setup.
>>
>>Any help would be appreciated!
>>
>>
>
>Set the use-store parameter in the cocoon.xconf to true, to enable
>caching of compiled stylesheets. It is false by default.
>
Is there still a reason why it set to false? It's true in Cocoon 2.0...
And I bet you can't get into production with 2.1 without enabling it...
Vadim
Re: setup method inside transformers, Performance?
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-09-24 at 15:51, manfred.weigel@rzb.at wrote:
> Hi,
>
> does anybody have any idea why calling the setup method for some
> transformers (like the stylesheet transfomer) takes up to 200 milliseconds?
> The execution of the transformer is comparably fast (60 ms), but we get a
> performance problem when we chain stylesheet transfomers which need 200 ms
> each for the setup.
>
> Any help would be appreciated!
Set the use-store parameter in the cocoon.xconf to true, to enable
caching of compiled stylesheets. It is false by default.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org