[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613199#action_12613199 ] Will Glass-Husain commented on VELOCITY-223: Hi, Thanks for all contributions on this old but important issue. I've dug into this a bit. Alexey's succinct analysis is correct (also described by Lei). Fundamentally, the issue is that every rendering of a template with macros creates a new String object containing the body of the macro. Alexey asks Why is it implemented this way? From a common-sense perpective, it seems like it would make more sense to parse the macro body, then share a common parse tree among all templates which use the macro. There are two reasons this is difficult (1) Macros are dynamically included at runtime, not parse-time. Different macros (with the same name) may be included with #parse (2) Templates are cached. I haven't investigated this in too much depth, but it seems likely to me that if the code shares a parse tree among different templates (or different templates included with #parse) it may run into caching/update issues. This is a long-winded way of note that I think the simplest solution is Lei's patch. Originally I thought this was a litle kludgy, but now I like the way it drastically saves memory without imposing the effort of redoing the existing macro mechanism. I'm setting up some before and after tests to verify the performance claims, but I just wanted to note I think this is the right way to go. VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613201#action_12613201 ] Will Glass-Husain commented on VELOCITY-223: Dear Lei, I cannot apply your patch to the Velocity code base as you did not check the box to grant the license to the ASF. Can you please respond stating I grant license to ASF for this patch for inclusion in ASF works (as per the Apache License ยง5) Thanks, WILL VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493509 ] Lei Gu commented on VELOCITY-223: - Hi Chris or Will, Please remove synchronized key word from ASTSetDirective.java's render method. It wasn't really necessary. Thanks. -- Lei VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489376 ] Alexey Panchenko commented on VELOCITY-223: --- Synchronization stringImagePool.get(image) should be inside synchronized block too. Memory Usage The memory held by private static MapString, String stringImagePool will be never released. The same applies to String.intern(). VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489392 ] Christopher Schultz commented on VELOCITY-223: -- Since Velocity already depends on commons-collections, why not use a ReferenceMap with non-hard references within StringImagePool? This way, you essentially get timeout behavior where old, unused keys (and values) will be GC'd. VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489416 ] Will Glass-Husain commented on VELOCITY-223: that makes sense to me. the memory issue is a good explanation of why it'd be useful to keep our own pool rather than use String intern() VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489435 ] Nathan Bubna commented on VELOCITY-223: --- Oh, and to finish out my conversation with Lei, he acknowledged that the synchronization of put() is useless and can be removed: On 4/2/07, Lei Gu [EMAIL PROTECTED] wrote: You got me there. I thought put will be called a lot less than get but you are right, we should be able to remove it as well. -- Lei Nathan Bubna wrote: On 4/2/07, Lei Gu [EMAIL PROTECTED] wrote: Hi Nathan, a) In the original code, a new copy of string image is constructed and returned as part of the token, which is part of a node. When we cache templates, these nodes stay in memory forever or until the template itself is booted from the cache. We improved this by checking against the string image pool. If the image already exists in the pool, the reference for the image is used instead of the newly created string. The newly created string will be garbage collected. cool. thanks for the explanation! b) This image pool is being called constantly and that's why we don't want to synchronized on the get call. It is okay to have one thread overwrites the other's string image and the overwritten images won't be lost if there could be existing references to them. i thought so. so why synchronize put() at all? doesn't it only delay the overwriting and slow things down needlessly? Thanks. -- Lei VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489434 ] Nathan Bubna commented on VELOCITY-223: --- Lei has tested and confirmed memory savings, and i see no reason to doubt that unless someone gets other results. His explanation of why it saved memory also makes sense. He sent it to the mailing list in response to my comments above, so i'll repost here: On April 2, Lei Gu said: Hi Nathan, a) In the original code, a new copy of string image is constructed and returned as part of the token, which is part of a node. When we cache templates, these nodes stay in memory forever or until the template itself is booted from the cache. We improved this by checking against the string image pool. If the image already exists in the pool, the reference for the image is used instead of the newly created string. The newly created string will be garbage collected. b) This image pool is being called constantly and that's why we don't want to synchronized on the get call. It is okay to have one thread overwrites the other's string image and the overwritten images won't be lost if there could be existing references to them. Thanks. -- Lei VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489437 ] Nathan Bubna commented on VELOCITY-223: --- So, all told. I think if we drop the static Map for a ReferenceMap (as Christopher suggested), drop the synchronization (as per the discussion between Lei and me), and retest to confirm the memory savings then this is ready to go into the codebase. VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486042 ] Will Glass-Husain commented on VELOCITY-223: Thanks, Lei! Also, see: http://www.mail-archive.com/dev@velocity.apache.org/msg01553.html VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
Hi Nathan, a) In the original code, a new copy of string image is constructed and returned as part of the token, which is part of a node. When we cache templates, these nodes stay in memory forever or until the template itself is booted from the cache. We improved this by checking against the string image pool. If the image already exists in the pool, the reference for the image is used instead of the newly created string. The newly created string will be garbage collected. b) This image pool is being called constantly and that's why we don't want to synchronized on the get call. It is okay to have one thread overwrites the other's string image and the overwritten images won't be lost if there could be existing references to them. Thanks. -- Lei Velocity - Dev mailing list-2 wrote: [ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486064 ] Nathan Bubna commented on VELOCITY-223: --- Those are great numbers! I'm excited to have a such potential boost to our velocimacro memory performance! Still, i have two questions... a) Why does this work? Clearly, i'm ignorant of the inner workings of the String class! I'd never have thought to try something like this. This is mysterious to me; i'd love to learn why this works. b) What good is the synchronization around the call to stringImagePool.put()? If we're concerned about stringImages stomping on one another, shouldn't we just use Hashtable or synchronize the whole method? VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: 223-patch.txt, AllVelocityMemoryByClass.html, StringImagePool.java, VelocityCharStream.java, VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-jira--Commented%3A-%28VELOCITY-223%29-VMs-that-use-a-large-number-of-directives-and-macros-use-excessive-amounts-of-memory---over-4-6MB-RAM-per-form-tf3506788.html#a9796510 Sent from the Velocity - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VELOCITY-223) VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form
[ https://issues.apache.org/jira/browse/VELOCITY-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475913 ] Ryan Smith commented on VELOCITY-223: - We have a web site where we use velocity to generate our HTML pages. Recently I was asked to help troubleshoot some performance issues and the root cause of our problem was that the velocity cache had grown to well over 1GB in size causing the JVM to continuously GC to try to free up memory. I used the YourKit memory profiler and found the following information about the individual velocity cache entries (see attached picture): Name Cache Size File Size --- VM_framework_library.vm 9,596,472 130,500 VM_buttons_library.vm 1,195,680 39,113 VM_layout_library.vm 1,683,256 54,371 admin/AdminHome.vm 32,505,168 979 poNewGrid.vm 14,399,648 753 poTemplateGrid.vm14,369,000 774 po/details.vm11,140,9528,368 sub.vm 10,115,096 24,576 VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form -- Key: VELOCITY-223 URL: https://issues.apache.org/jira/browse/VELOCITY-223 Project: Velocity Issue Type: Bug Components: Engine Affects Versions: 1.3.1 Environment: Operating System: All Platform: All Reporter: Christian Nichols Fix For: 1.6 Attachments: VelocityMemory.JPG Our application FinanceCenter is based on Velocity as the template engine. We have a library of about 200 macros and about 400 VM files. Because the velocity parser copies the macro body into the VM during parsing, macros that are frequently used (even though identical and using local contexts) use up large amounts of memory. On our Linux server (running Redhat 7.2 with Sun JDK 1.4.1_04) we can easily use up over 1GB of RAM simply by opening up many forms (about 150) - the server starts out using 60MB after startup. This memory times out after 5 minutes and is returned which tells me that it is screen memory. Our problem is that the NT JVM and Linux JVM (32 bit) are currently limited to about 1.6 - 2.0 GB of ram for heap space. Thus, using a fair number of forms in the application leaves little space for user session data. We have implemented a caching mechanism for compiled templates and integrated it into Velocity so that cached objects are timed out of the cache but the server is still using large amounts of memory. We finally had to rewrite many of our macros into Java so that memory usage would be reduced (note that these macros were doing complex screen formatting not business logic). Doing this has reduced our memory by about 30%. This is currently our biggest issue with Velocity and is causing us to review our decision to stay with Velocity going forward. This is because we will likely end up with close to 1,000 forms by the end of next year and need to know that Velocity can deal with this. Is there any work underway to share compiled macro AST's? This would greatly reduce the amount of memory used. I have reviewed the parser code that is doing this but it seems that this is an embedded part of the design and not easily changed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
