Uploaded image for project: 'Velocity'
  1. Velocity
  2. VELOCITY-223

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



    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 1.3.1
    • 1.6
    • Engine
    • None
    • Operating System: All
      Platform: All
    • 24375


      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.


        1. VelocityMemory.JPG
          63 kB
          Ryan Smith
        2. VelocityCharStream.java
          13 kB
          Lei Gu
        3. StringImagePool.java
          0.5 kB
          Lei Gu
        4. AllVelocityMemoryByClass.html
          78 kB
          Ryan Smith
        5. 223-patch.txt
          2 kB
          Lei Gu



            Unassigned Unassigned
            chrisn@capitalstream.com Christian Nichols
            1 Vote for this issue
            2 Start watching this issue