cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: AW: Status of XMLCompiler - Please vote...
Date Wed, 17 Jan 2001 15:37:15 GMT
> Berin Loritsch wrote:
> The Cocoon project calls them Generators.  Let's keep the same name.
> Here is my spin on it: if the events will be called quicker by actually
> compiling a class and calling the methods like XSP, then we should
> determine by how much very easily.
> Take two files of roughly 100k each.  The _only_ difference between them
> should be that one is treated as an XSP, and the other as an XML page.
> There should be no tranlators involved, and serialized as XML.
> NOTE: the XSP page may require the use of the <xsp:page> tags as the
> root.
> For an example of a small page like this, look at
> webapp/docs/samples/forms/add-department.xsp
> Access them each 11 times (throwing away the first time).  Average the
> last ten times (the compile is the first access).  If the average of
> the compiled sheet is significantly faster than the average of the
> uncompiled sheet, then it might be worth investigating this further.
> Otherwise, lets cut our losses because the RCT (Really Cool Technology)
> won't buy us enough of a performance edge.
> The next test is to create a Generator that reads the file into a string,
> and parses the string over and over--using the same test and test file.
> Then you will see what caching at the XML level will and will not do
> for you.
Attached are the performance results Stefano made when he startet the XMLCompiler.
> My take is that for static pages, we cache the final result.  For
> dynamic pages we cache from the most static portion (Cocoon 2 really
> already does this for XSP--because the classloader caches the
> serverpages Generators).
I agree absolutely and for non XSP-pages the caching of the most static
portion *could* (not must) be done by the XMLCompiler.


View raw message