J: > 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
