Re: Updated Benchmark Available

Paul Tchistopolskii wrote:
>  
> > Q: From the practical point of view, the result of this benchmark could be
> > formulated as follows:
> >
> > "... All XSLT processors (except those crashed) demonstrated a good
> > performance ..." (0.6 sec is a good response time - isn't it?)
> 
> A: If your transformation consists of 5 sub-transformations  ( page
> consists of 5 'sub-pages' )  the total responce time for  the
> page is 3 sec. This is not a good responce time, I think.
> 

I agree.

However, for mission-critical tasks the XSLT processor should be,
ideally, loaded persistently in memory, initialized just once, should
provide cache for all relevant resources, etc. In particular, I would
never use the stand-alone command line tools in mission-critical
realtime environments.

> > Q: I also could not understand why the issue whether the XSLT processor is
> > using the "pre-parsed" stylesheets is so important. Some processors do
> > it, some don't, but the efficiency of this feature in fact depends on
> > the processor architecture and on the way how this pre-parsing is
> > integrated with the other processor components.
> 
> A: I agree that pre-parsed stylesheets could be not critical for some
> environments, but I think it is actually easier to implement
> some brutal pre-parsed stylesheets instead of  argue about them.
> 
> In simple case pre-parsed stylesheets are saving the time of
> compilation .XSL into internal representation of the stylesheet
> and no matter what is the XSLT engine architecture this
> compilation could be easeily avoided.  Or you see some
> other scenario when XSLT engine does not go from .XML
> to internal representation?
> 
> Pre-parsing is important. Sometimes.
> 

I agree.

Indeed, I do pre-parsing in my own XSLT implementation.

But anyway, why should not we consider the original posting in this
thread as what it really is - as the smart announcement of Napa?

Regards,

Alexey


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list