XSP speedup [was Re: Cocoon 2.0 Scalability Disappointment]

[Sylvain Wallez <sy...@anyware-tech.com>]

Sylvain Wallez a écrit :
> 
> Stefano Mazzocchi a écrit :
> >
> > Michael told me privately the numbers that he has been experiencing
> > along with a description of his environment and I now agree with him, we
> > have a serious scalability problem.

<snip/>

> There's a CPU/memory eater in ServerPagesGenerator : each startElement
> is stored in a stack in order to properly close all opened elements in
> case of premature end of the XSP (return statement or exception). Cocoon
> 1 didn't have this because of the use of DOM : even if partially
> generated, the DOM is always a valid XML document.
> 
> This stack is a LinkedList to which EventData objects are appended. This
> means for each element, 2 objects are allocated : the EventData object,
> and a LinkedList node. We can change this stuff to use a single
> ArrayStack (from excalibur.collections) and no EventData object, which
> should significantly reduce CPU consumption.
> 
> But the real question is : can an XSP be considered valid if it contains
> a "return" statement ? I personnaly never saw such XSPs. Also, this
> stuff is only a half protection against bogus code in the XSP : it will
> take care of having as much closed elements as opened ones, but doesn't
> check proper balancing nor do anything for constructs like a "break" in
> a loop inside an XML element.
> 
> So my opinion is remove this costly stuff and forbid return statements
> in xsp:logic. This will make a speedy XSP engine.

After more thinking, I came to the conclusion that using a "return" to
break prematurely the XSP generation is **really bad** : some
logicsheets (e.g. ESQL) generate additional "segmentation methods" to
circumvent the 64 kb limit imposed by the JVM for the bytecode size of a
single method. If someone uses return statements to prematurely end an
XSP that uses such a logicsheet, he may either end the full XSP or end a
part of it if the "return" gets generated in a segmentation method, in
an uncontrolled way (decided by the logicsheet).

Since we cannot really know what the return statement will actually do,
this should be considered a bad practice which should be avoided (once
again, I never saw such a return statement in an XSP). And IMO we
shouldn't harm performances of the XSP engine to support bad practices.

So I refactored ServerPagesGenerator in both 2.0 and 2.1 to make
document completion optional (it is disabled by default), and faster if
enabled through the use of an ArrayStack instead of a LinkedList.

Michael, could you please update your performance measurements and tell
us if this leads to a significant change ?

Sylvain.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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