Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <355ACE33C543D7489C3A286647574F8207CDFC@slider.cactus.ca>
From: philippe.lavoie@cactus.ca
To: cocoon-dev@xml.apache.org
Subject: RE: Odds of having Xalan2 with C1 ?
Date: Mon, 9 Apr 2001 13:45:36 -0400 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"


This no caching issue also applies with XSP ?

Just curious,

Phil

-----Original Message-----
From: Berin Loritsch [mailto:bloritsch@apache.org]
Sent: Monday, April 09, 2001 12:53 PM
To: cocoon-dev@xml.apache.org
Subject: Re: Odds of having Xalan2 with C1 ?


philippe.lavoie@cactus.ca wrote:
> 
> This might have been discusses before and I apologize for asking it again.
> 
> Are there any plans to have C1 working with Xalan2 ?
> 
> We are having speed issues, i.e. the servlet version is a lot faster then
> the C1 version and are hopping that Xalan2 would speed things up.

There are probably several reasons why Cocoon is not going to be faster than
a strict Servlet version.  But, there are some compelling reasons to use
Cocoon 2 over Cocoon 1 if speed is critical.

The first issue is a well known architectural issue.  Cocoon 1 is based on
DOM, mainly because that's where the tools were available, and DOM is easier
to program with.  Cocoon 2 is bsaed on SAX, as is Xalan2, and the speed
difference is obscene.  Simple Servlets provide no transformations and
basically,
to change the look of a page you change code.  They are comparably _VERY_
fast.

Another issue, connected with the DOM vs. SAX architecture, has to do with
stages in the pipeline.  In Cocoon 1, due to the DOM architecture, each
producer, transformer, and serializer has a distinct beginning and end.
You start with a Docuement tree, and each transformer applies different
transformations to it, and then it is serialized.  In Cocoon 2, due to
the SAX architecture, each SAX event is propogated through the pipeline
until it is serialized, or dropped.  That means that you are seeing portions
of the output as the Generator is going through portions of the input.
This lends to both a measured and perceived performance increase.

Lest you think I am dogging Cocoon 1, I am not.  Cocoon 1 has the benefit of
more taglibs, caching, and more support.  Cocoon 2 has the benefit of an
optimized architecture, stability, and some cutting edge features.  Cocoon 2
does not *yet* have a cache implemented (currently in earnest progress).

For sites that are largely static, and unchanging, I will recommend Cocoon
1,
because the cache is excellent and is faster than Cocoon 2.  For dynamic
sites and webapps, I will recommend Cocoon 2 because of the optimized
architectural changes, and the Action facilities.  I am using it for a
Webapp my company is developing, so it meats our robustness qualifications.
We have run some serious bombardment of Cocoon 2 simulating 1 million and
2 million hits in a 24 hour period, and Cocoon 2's performance degrades
mroe gradually than Cocoon 1 due to the lower memmory overhead required
for SAX vs. DOM.

In most cases, there is little rework that needs to be done in order for
Cocoon 2 to support what you have created in Cocoon 1.

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

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