> No offense meant, but most people start with the most
> inefficient ways to generate XML, usually doing a
> lookup in a remote database (which is slow, but hard to
> avoid), building an XML string or a DOM tree (which is
> slow, memory consuming and avoidable) and then feed it
> to the XSLT processor.

This is what we do and I agree it's far from the most efficient way to
handle reports that can get very large. But right now the issues we have
with FOP on memory consumption and speed degradation during concurrent
processing are an order of magnitude higher than with XML generation (ie - 3
minutes FOP vs. 20 sec. XML generation time for a very large report). I'm
not complaining, just stating. 

Also at least as far as our app I would con concur that XSLT resource
consumption is the least of our worries. XSLT time is at least an order of
magnitude *less* than the XML generation piece. From my experience if you
keep the XML well-structured to the data, the XSLT comes out relatively
simple with few calculations and speed/memory is not an issue.

Matt Savino


Reply via email to