AW: question about performance
hi.. thanks guys for some answers... i think i'll doing some experiments with the performance using the xalan... i suspect that it was the FO-Processor that took the most resources, because i have some graphics in the header, and page-citation in the footer .. a little bit out of topic.. my supervisor told me this morning, that i should take TeX/LaTeX to produce the pdf...he said, it should be faster with TeX .. what i mean here is not the FO-Processor from Passive-TeX, but pure TeX,... using Java to get the input from the database and then generate the pdf using pdfTeX library, or something like that does anyone here have any experience with TeX and can told me about the performance greets sandy -Ursprüngliche Nachricht- Von: Clay Leeds [mailto:[EMAIL PROTECTED] Gesendet am: Dienstag, 25. Mai 2004 20:22 An: [EMAIL PROTECTED] Betreff: Re: question about performance Sandy, On May 25, 2004, at 11:04 AM, Andreas L. Delmelle wrote: Hmm... XSL-FO is designed exactly to serve purposes like this. That being said: is it actually FOP's processing that takes a long time, or is it the XSL transform? Can you test this a bit maybe? Run the XSL transform separately (preferrably also through another processor than Xalan to compare results). Just adding this, because I know out of experience that 'newbie' code can easily drain an XSLT processor's resources. Things like double forward slashes ( '//*' ) might seem 'handy' in being able to retrieve a node from any context in the stylesheet, but an explicit XPath expression pointing at exactly the right node saves the processor a few (--possibly quite a few) unnecessary tree traversals. Also, could you do a bit more research on whether it is the context of the servlet that creates the delay? Try rendering the same XML+XSLT via the command-line, and see if there's any noticeable difference... Hope this helps! Greetz, Andreas To continue a bit on where I think Andreas was headed, there's a script distributed with FOP, you can use to test the XSL portion: Xalan. The scripts are called 'xalan.bat' (Windows/DOS) and 'xalan.sh' (the rest of us) The cmd line is simple: xalan.sh version: xalan.sh -IN input.xml -XSL input.xsl -OUT output.fo xalan.bat version xalan.bat -IN input.xml -XSL input.xsl -OUT output.fo There are other commands which you can see by running xalan.bat/xalan.sh with no arguments. Hope this helps! Web Maestro Clay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
question about performance
hi ... you can say that i'm a newbie in this FOP technology...infact, xml is a new area for me.. i want to use FOP to generate reports from our database... i tried some examples from the fop distribution..and then i made some experience, to generate a table with 12 columns and about 1000 rows from datas from xml ...it looks like this daten WDB123/WDB WDB2004321/WDB2004 WDB2003587/WDB2003 WDB2002456/WDB2002 WDB2001159/WDB2001 WDBA123/WDBA WDB2004B321/WDB2004B WDB2003C587/WDB2003C WDB2002D456/WDB2002D WDB2001E159/WDB2001E WDBF123/WDBF WDB2004G321/WDB2004G /daten later i found the problem,. that it tooked about 4-5 minutes to complete the request under servlet.. the table that I made from the stylesheet was very2 simple, without any graphic or something like that my questions : 1. would it be better if I use iText for large documents,... pick up the data directly from database 2 my friend told me, that I should use rather DOM file than XML file,it will be faster...is it true ? 3. have u guys any idea, what is the best solutions , to generate PDF from a large database , and that's on the fly.. thanks sandy soesilo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: question about performance
-Original Message- From: [EMAIL PROTECTED] Hi, snip / my questions : 1. would it be better if I use iText for large documents,... pick up the data directly from database It could well be (depends on your code, anyway :) ) Downside of course is maintenance of this piece of software. Maybe there are a few standardized solutions out there that fit your description, I'm not sure. 2 my friend told me, that I should use rather DOM file than XML file,it will be faster...is it true ? Yes, but ... DOM first has to create an object structure representing the document in memory, so can be quite a mem-eater if the source XML is large (--on top of that: creating the document representation also has its cost) The advantages of DOM over SAX depend largely on what you actually need to extract from the source XML, whether you need repeated access to the same nodes etc. For as far as I understand FOP's processing model: SAX is used to parse the input XML (FO), and the generated SAX events are caught and mapped to an object-tree. ( Each SAX event creates a certain type of object in the FOTree ) In essence, all the FO nodes in the source document are accessed only once, namely to create an FObj representing it. IIC, this makes using a DOM input source rather suboptimal, since first the DOM representation must be created, and then that tree is used merely to create another tree --anyway, the nodes are accessed only once... Don't get this the wrong way: DOM might be useful for the source XML to the XSL transform which creates the FO, especially if you need to transform the same XML document multiple (make that: numerous) times. 3. have u guys any idea, what is the best solutions, to generate PDF from a large database, and that's on the fly.. Hmm... XSL-FO is designed exactly to serve purposes like this. That being said: is it actually FOP's processing that takes a long time, or is it the XSL transform? Can you test this a bit maybe? Run the XSL transform separately (preferrably also through another processor than Xalan to compare results). Just adding this, because I know out of experience that 'newbie' code can easily drain an XSLT processor's resources. Things like double forward slashes ( '//*' ) might seem 'handy' in being able to retrieve a node from any context in the stylesheet, but an explicit XPath expression pointing at exactly the right node saves the processor a few (--possibly quite a few) unnecessary tree traversals. Also, could you do a bit more research on whether it is the context of the servlet that creates the delay? Try rendering the same XML+XSLT via the command-line, and see if there's any noticeable difference... Hope this helps! Greetz, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: question about performance
Sandy, On May 25, 2004, at 11:04 AM, Andreas L. Delmelle wrote: Hmm... XSL-FO is designed exactly to serve purposes like this. That being said: is it actually FOP's processing that takes a long time, or is it the XSL transform? Can you test this a bit maybe? Run the XSL transform separately (preferrably also through another processor than Xalan to compare results). Just adding this, because I know out of experience that 'newbie' code can easily drain an XSLT processor's resources. Things like double forward slashes ( '//*' ) might seem 'handy' in being able to retrieve a node from any context in the stylesheet, but an explicit XPath expression pointing at exactly the right node saves the processor a few (--possibly quite a few) unnecessary tree traversals. Also, could you do a bit more research on whether it is the context of the servlet that creates the delay? Try rendering the same XML+XSLT via the command-line, and see if there's any noticeable difference... Hope this helps! Greetz, Andreas To continue a bit on where I think Andreas was headed, there's a script distributed with FOP, you can use to test the XSL portion: Xalan. The scripts are called 'xalan.bat' (Windows/DOS) and 'xalan.sh' (the rest of us) The cmd line is simple: xalan.sh version: xalan.sh -IN input.xml -XSL input.xsl -OUT output.fo xalan.bat version xalan.bat -IN input.xml -XSL input.xsl -OUT output.fo There are other commands which you can see by running xalan.bat/xalan.sh with no arguments. Hope this helps! Web Maestro Clay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
