[
https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659123#action_12659123
]
Nathan Bubna commented on VELOCITY-648:
---------------------------------------
Surprises are not ideal. As i'm having neither memory issues nor this as a
bottleneck, i'm not inclined to express a preference here. I do, however,
think documentation is key. If we do change the default size to 0, then we
need to document this very loudly in the release notes. If not, then perhaps
we should add a "Performance Tips" section to the Developer's guide where we
recommend this change for speed.
> Non zero resource cache size slower
> -----------------------------------
>
> Key: VELOCITY-648
> URL: https://issues.apache.org/jira/browse/VELOCITY-648
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Reporter: Byron Foster
> Fix For: 1.7
>
>
> In performance testing I found that setting the
> resource.manager.defaultcache.size property to 0 increases performance by
> about 30%. The reason for this is that when the cache size is set to 0
> Velocity uses the java.util.concurrent.ConcurrentHashMap container which
> provides better thread concurrency. when the cache size is set to a non-zero
> value Velocity uses the org.apache.commons.collections.map.LRUMap container,
> which provides poor concurrency. The problem is that It's unclear if there
> is a container that provides both good concurrency, and has a max size
> setting.
> The default cache size is 89, which uses the slower LRUMap, and the end user
> is non the wiser. The best solution would be to find a container that can be
> used in both cases that performs as well as the ConcurrentHashMap, otherwise
> a discussion in the documentation is probably warranted.
--
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]
