DO NOT REPLY [Bug 24375] New: - VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24375>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24375

VMs that use a large number of directives and macros use excessive amounts of memory - over 4-6MB RAM per form

           Summary: VMs that use a large number of directives and macros use
                    excessive amounts of memory - over 4-6MB RAM per form
           Product: Velocity
           Version: 1.3.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Source
        AssignedTo: velocity-dev@jakarta.apache.org
        ReportedBy: chrisn@capitalstream.com


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.

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org