On 3 October 2011 13:14, Philippe Mouawad <philippe.moua...@gmail.com> wrote:
> Sebb,
> Do you want me to provide a patch with ConcurrentHashMap where I will have
> to handle null keys and values (not same behaviour as HashMap) or we forget
> about this approach ?
I don't think we have yet decided how best to handle concurrent downloads.
e.g. should they even be setting cookies?
> Regards
> Philippe
>
> On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad <philippe.moua...@gmail.com
>> wrote:
>
>> Hello,
>> Just a little update on my test.
>> I added a clear and gc before each Map instanciation and results are
>> different:
>>
>> - HashMapput:645
>> - ConcurrentHashMapput:832
>> - ConcurrentReaderHashMapput:620
>> - HashMap get:17
>> - ConcurrentHashMap get:32
>> - ConcurrentReaderHashMap get:60
>>
>>
>> So it kind of closes the debate, sorry for disturbance.
>> Regards
>> Philippe
>>
>>
>>
>>
>> public class TestMap {
>>
>> public static void main(String[] args) {
>> StopWatch timer = new StopWatch();
>>
>> Map map = new HashMap();
>> testPut(timer, map, "HashMap");
>> timer.reset();
>>
>> map.clear();
>> System.gc();
>>
>> map = new ConcurrentHashMap();
>> testPut(timer, map, "ConcurrentHashMap");
>> timer.reset();
>>
>> map.clear();
>> System.gc();
>>
>> map = new ConcurrentReaderHashMap();
>> testPut(timer, map, "ConcurrentReaderHashMap");
>> timer.reset();
>>
>>
>> map.clear();
>> System.gc();
>>
>> map = new HashMap();
>> testGet(timer, map, "HashMap");
>> timer.reset();
>>
>> map.clear();
>> System.gc();
>>
>> map = new ConcurrentHashMap();
>> testGet(timer, map, "ConcurrentHashMap");
>> timer.reset();
>>
>> map.clear();
>> System.gc();
>>
>> map = new ConcurrentReaderHashMap();
>> testGet(timer, map, "ConcurrentReaderHashMap");
>> timer.reset();
>> }
>>
>> /**
>> * @param timer
>> */
>> private static void testGet(StopWatch timer, Map map, String type) {
>> timer.start();
>> for (int i = 0; i < 1000000; i++) {
>> map.get(i);
>> }
>> timer.stop();
>> System.out.println(type+" get:"+timer.getTime());
>> }
>>
>> /**
>> * @param timer
>> */
>> private static void testPut(StopWatch timer, Map map, String type) {
>> timer.start();
>> for (int i = 0; i < 1000000; i++) {
>> map.put(i,i);
>> }
>> timer.stop();
>> System.out.println(type+"put:"+timer.getTime());
>> }
>>
>>
>> Regards
>> Philippe
>>
>>
>> On Mon, Oct 3, 2011 at 1:37 PM, sebb <seb...@gmail.com> wrote:
>>
>>> On 3 October 2011 12:15, Rainer Jung <rainer.j...@kippdata.de> wrote:
>>> > On 02.10.2011 23:17, Philippe Mouawad wrote:
>>> >> Ok, hope we can do the same.
>>> >
>>> > See https://issues.apache.org/jira/browse/XMLBEANS-447
>>> >
>>> > We are not the only people, who doubt it's correct to include that class
>>> ...
>>> >
>>> > There was also a discussion some time ago in another ASF project,
>>> > because the Sun license which is cited by Doug Lea has a "no use in
>>> > nuclear facilities clause", which make it non-usable as an Open Source
>>> > license.
>>> >
>>> > It looks like we are stuck here.
>>>
>>> Yes, apart from the binary option which brings in lots of unneeded code.
>>>
>>> > And the mentioning of the Harmony class in the above cited issue is a
>>> > red herring. Diffing it with the JDK 5 standard ConcurrentHashMap shows
>>> > little difference, so I doubt it will be much faster (though I didn't
>>> > inspect the delta in detail).
>>>
>>> I think the Harmony class was only mentioned as a means of supporting
>>> Java 1.4, not as an alternative faster implementation.
>>>
>>> >> I must say I don't understand why ConcurrentReaderHashMap is not in
>>> JDK.
>>> >
>>> > There's a discussion list for JSR166 (the concurrency stuff lead by Doug
>>> > Lea) mentioned on the JSR 166 page maintained by Doug Lea. So maybe you
>>> > can post a technical question there (what's the right class that solve
>>> > the following problem ... and doesn't have sun licensing restrictions).
>>> >
>>> > Regards,
>>> >
>>> > Rainer
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> > For additional commands, e-mail: dev-h...@jakarta.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
>>> For additional commands, e-mail: dev-h...@jakarta.apache.org
>>>
>>>
>>
>>
>> --
>> Cordialement.
>> Philippe Mouawad.
>>
>>
>>
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org
