Improving XSLT performance

[Gary Larsen <ga...@envisn.com>]

Some large XQuery results are taking along time to process and I'm looking
for suggestions on how to improve XSLT performance.

I'm currently using Cocoon 2.1.7 with Xalan Java 2.4.1.  I tried to plug in
Xalan Java 2.7.0 but it turns out I will need to upgrade Cocoon.  My next
step is to see if Saxon will work with 2.1.7.

Will an upgrade of Xalan or moving to Saxon improve performance?

Another question:

The answer is 'probably it depends', but generally speaking is the upgrade
to 2.1.* (from 2.1.7) very difficult for most applications?  Is there info
anywhere on upgrading?  What would be other justifications for an upgrade?

Thanks for any advice,
Gary



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

RE: Improving XSLT performance

[Gary Larsen <ga...@envisn.com>]

Thanks for the info! 

-----Original Message-----
From: thomason [mailto:thomason@physio1.utmem.edu] 
Sent: Friday, January 05, 2007 3:42 PM
To: users@cocoon.apache.org
Subject: Re: Improving XSLT performance

on 1/5/07 1:07 PM, Gary Larsen at gary.larsen@envisn.com wrote:
> The answer is 'probably it depends', but generally speaking is the 
> upgrade to 2.1.* (from 2.1.7) very difficult for most applications?  
> Is there info anywhere on upgrading?  What would be other justifications
for an upgrade?
 
It has been pretty much been plug-and-play when I have migrated several
large apps with each new release (2.1.4 through 2.1.10; 2.2 seems to be a
different issue).
Reason to upgrade: improved/added features and stability (e.g. newjx, ajax).
If you are using jx for CForms, the performance of the newjx generator is
worth an upgrade.
Biggest gotcha: forgetting to include app specific jars in the build (e.g.,
activation, mail, saxon). You can drop them in the lib afterward and
restart.
Most extensive required modification: in form templates, changing the action
attribute in the ft:form-template element from
action="#{$continuation/id}.continue" to
action="#{$cocoon/continuation/id}.continue" for the newjx generator.

I'm sure there have been other minor changes associated with an upgrade, but
these have not been difficult or time consuming.
 



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


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

Re: Improving XSLT performance

[thomason <th...@physio1.utmem.edu>]

on 1/5/07 1:07 PM, Gary Larsen at gary.larsen@envisn.com wrote:
> The answer is 'probably it depends', but generally speaking is the upgrade
> to 2.1.* (from 2.1.7) very difficult for most applications?  Is there info
> anywhere on upgrading?  What would be other justifications for an upgrade?
 
It has been pretty much been plug-and-play when I have migrated several
large apps with each new release (2.1.4 through 2.1.10; 2.2 seems to be a
different issue).
Reason to upgrade: improved/added features and stability (e.g. newjx, ajax).
If you are using jx for CForms, the performance of the newjx generator is
worth an upgrade.
Biggest gotcha: forgetting to include app specific jars in the build (e.g.,
activation, mail, saxon). You can drop them in the lib afterward and
restart.
Most extensive required modification: in form templates, changing the action
attribute in the ft:form-template element from
action="#{$continuation/id}.continue" to
action="#{$cocoon/continuation/id}.continue" for the newjx generator.

I'm sure there have been other minor changes associated with an upgrade, but
these have not been difficult or time consuming.
 



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