Re: [xslt] XSLT and Safari

[Daniel Veillard <veillard redhat com>]

On Mon, Aug 16, 2004 at 05:28:05PM -0700, Dave Hyatt wrote:
> With a sync I/O approach, you lose all ability to parallelize loads.  
> If one sheet wants to import three other sheets (A, B, and C), then 
> libxslt's model will force you to load A, then load B, and then load C. 
>  My model will allow me to kick off all three loads at once.  This 
> seems clearly better to me.  If B loads first and wants to import two 
> more sheets (D and E), I could get those loads kicked off even before A 
> or C had finished, etc.

  This work for stylesheet compilation, not for document loaded at runtime
because the URLs are usually generated on-the fly. My experience is that
unless you have a significant network lag, stylesheet compilation is
neglectible compared to actually running the transformation. And the
best for handling that is to have a pool of the most recently precompiled
stylesheets. Stylesheets are read-only at transformation time.
  I'm a bit worry by trying to optimize early on while you don't have a
full grasp of how the system will have to work in practice. You're doing
design choices which may be efficient or counter-productive and it's
hard to tell in advance what will work from what not. My own principle
is to KISS (keep it simple stupid) and then chase bottlenecks when they
show up. 
  For example parallelism of stylesheet resources is likely to help,
but if most stylesheets don't do any import or include then you're
paying a tree traversal for nothing, the effectiveness really depends
on the kind of stylesheets you're actually hitting.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/