You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Byron Foster (JIRA)" <de...@velocity.apache.org> on 2008/11/24 20:41:44 UTC
[jira] Created: (VELOCITY-648) Non zero resource cache size slower
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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Issue Comment Edited: (VELOCITY-648) Non zero resource cache
size slower
Posted by "Byron Foster (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659167#action_12659167 ]
byronvf edited comment on VELOCITY-648 at 12/24/08 2:55 PM:
-----------------------------------------------------------------
Something like this would be nice for the 0 case:
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ReferenceMap.html
But apache common collections doesn't seem to have an equivalent.
was (Author: byronvf):
Something like this would be nice for the 0 case:
http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/package-summary.html
But apache common collections doesn't seem to have an equivalent.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Closed: (VELOCITY-648) Non zero resource cache size slower
Posted by "Byron Foster (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Byron Foster closed VELOCITY-648.
---------------------------------
Resolution: Invalid
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-648) Non zero resource cache size
slower
Posted by "Jarkko Viinamäki (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658978#action_12658978 ]
Jarkko Viinamäki commented on VELOCITY-648:
-------------------------------------------
It's very very difficult to create a bounded map that performs as well as the ConcurrentHashMap - especially using the LRU algorithm.
Should we make default value for defaultcache 0 so that ConcurrentHashMap would kick in by default? If the user then runs into OutOfMemory problems (too many templates in memory), he could change to bounded LRUMap. This might be ok since template memory consumption has decreased significantly since 1.5. Of course this might surprise many users who expect the same default behaviour that was in earlier releases.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-648) Non zero resource cache size
slower
Posted by "Byron Foster (JIRA)" <de...@velocity.apache.org>.
[ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-648) Non zero resource cache size
slower
Posted by "Byron Foster (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659167#action_12659167 ]
Byron Foster commented on VELOCITY-648:
---------------------------------------
Something like this would be nice for the 0 case:
http://google-collections.googlecode.com/svn/trunk/javadoc/index.html?http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/package-summary.html
But apache common collections doesn't seem to have an equivalent.
> 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Commented: (VELOCITY-648) Non zero resource cache size
slower
Posted by "Nathan Bubna (JIRA)" <de...@velocity.apache.org>.
[ 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: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org