Speaking of performance, we have a simple performance benchmark application[1] that renders a 5x50
table grid (It contains implementations for other well known frameworks as well). Would be
interesting to see if the different Map implementations will impact this test.
kind regards
bob
[1]: http://svn.apache.org/repos/asf/click/trunk/examples/click-bench/
On 5/03/2010 07:56 AM, Henry Saputra wrote:
HI Malcolm,
If you think the risk is too high for now could we just leave it open so
it could be revisited later?
Sorry about keep pushing about this but maintaining legacy code is a
pain and could have impact on performance.
Thanks,
- Henry
On Thu, Mar 4, 2010 at 11:14 AM, Henry Saputra <[email protected]
<mailto:[email protected]>> wrote:
Hi Malcolm,
Thanks for your input for this bug.
I understand the risk but I dont think this is the right solution
since the more Java move to better concurrency support, sticking
with the "deprecated" class will make the framework to be sluggish.
Removing this dependency on Doug's concurrency package to Java EE
concurrency package and supporting Java generics should make the
Click framework to be more faster and efficient.
I have used Spring 2.5 before with Java concurrent package before
and never see any problem.
- Henry
On Thu, Mar 4, 2010 at 4:11 AM, Malcolm Edgar (JIRA)
<[email protected] <mailto:[email protected]>> wrote:
[
https://issues.apache.org/jira/browse/CLK-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Malcolm Edgar closed CLK-636.
-----------------------------
Resolution: Won't Fix
I appreciate the though around this issue but risk to production
applications using various Spring version is too high for the
reward of removing this class.
regards Malcolm Edgar
> Replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap with
java.util.concurrent.ConcurrentHashMap
>
------------------------------------------------------------------------------------------------------------
>
> Key: CLK-636
> URL:
https://issues.apache.org/jira/browse/CLK-636
> Project: Click
> Issue Type: Improvement
> Components: core
> Affects Versions: 2.2.0
> Reporter: Henry Saputra
> Attachments: concurrentreader_patch.diff
>
>
> Since Click required Java SDK 1.5 or later, we could leverage
the java.util.concurrent.ConcurrentHashMap class to replace
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class
so reducing the Click runtime dependency.
> In my opinion here are some good reasons why:
> 1. The ConcurrentHashMap class in Java SDK is more efficient
since it utilizes internal hash classes to support better
granularity and concurrency compare to simple syncrhonized on
the instance like in
DU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap.
> 2. Looking at the use case ConcurrentReaderHashMap in Click,
it used to cache the OGNL expression (please correct me if I am
wrong). This scenario does not need exclusive lock on update
which is the intended/ preferred use case for
ConcurrentReaderHashMap. If there is a miss on OGNL expression
on a name in the cache, it will cerate one and put it to the map
if no other thread has not. So it will still perform as well as
or better locking entire table. However, if we do need exclusive
lock on update, we can simulate ConcurrentReaderHashMap with
ConcurrentHashMap by setting concurrencyLevel to one.
> 3. The ConcurrentHashMap support generic which is part of
task being done to move Click code to Java generics.
> 4. Looks like the
EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap class
is created by Doug Lea before contributions to
java.util.concurrent packages in Java 1.5 SDK so the code may no
longer optimized.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
