Malcolm, Thanks for your response. I hesitated at including too many details in case I just needed to RTFM. As it turns out, that's exactly what I needed to do. I have #parse embedded in a #foreach loop and I had template caching turned off. Since I've turned it on, the resulting application is very nearly as responsive as the older application with the embedded 'println()' calls.
Thanks to everyone on the list for their help. John John Withers -----Original Message----- From: Malcolm Edgar [mailto:[EMAIL PROTECTED] Sent: Friday, May 27, 2005 5:43 PM To: Velocity Users List Subject: RE: Performance tuning and Velocity Hi John, how many items are you displaying? You will probably need to provide a lot more configuration info get to some useful answers from this list. Note with only JVM's 1.2 etc. you are better off using ArrayList as its unsyncronised, but with latter JVM it doesn't make much difference. Not that this issue would explain why this is running so slow. regards Malcolm Edgar -----Original Message----- From: Withers John Z [mailto:[EMAIL PROTECTED] Sent: Saturday, 28 May 2005 7:17 AM To: 'Velocity Users List' Subject: Performance tuning and Velocity Hello all. I've just converted a stand-alone web server application from using embedded 'println()' to using Velocity to produce output. The results display very well, but now I'm having some performance related issues. For a given query from the applications input form, the 'antique' version responds in 35 seconds while the Velocity version takes over 90 seconds to complete. The difference increases as the number of items are displayed. I suspect my underlying approach for using Velocity is at fault here. In both cases, the server application evaluates the users input data and retrieves it from a data store (in this case, an LDAP server). The retrieved data is stored in a java.util.Vector. This Vector is placed in the VelocityContex. The target template iterates through the vector with a #foreach() and lays out each individual item from the Vector. Is there a better way to approach this issue? Thanks! NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank.
