[
https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660464#action_12660464
]
Byron Foster commented on VELOCITY-648:
---------------------------------------
I benchmarked this some more and it looks like it may not be a big issue.
Under a profiler it can be shown that there is thread contention, but over all
through put is only slightly effected. Overall I don't think it's a big deal.
I updated the docs with a little more description.
> 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]
