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 >> >> >> 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] >> >> > > --------------------------------------------------------------------- > 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#a9796732 Sent from the Velocity - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
