[
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]
