I am happy to leave this issue open, to be revisited latter. regards Malcolm Edgar
On Fri, Mar 5, 2010 at 8:56 AM, Bob Schellink <[email protected]> wrote: > 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. >> >> >> > >
