[jbosscache-dev] Immutables.immutableSetCopy

[Brian Stansberry]

On 08/20/2009 11:00 AM, Manik Surtani wrote:
>
> On 20 Aug 2009, at 16:12, Brian Stansberry wrote:
>
>> This didn't seem to go through; apologies for spam if it did.
>>
>> -------- Original Message --------
>> Message-ID: <4A8C79BF.3000103 at redhat.com>
>> Date: Wed, 19 Aug 2009 17:16:31 -0500
>> From: Brian Stansberry <brian.stansberry at redhat.com>
>> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1)
>> Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
>> MIME-Version: 1.0
>> To: jbosscache-dev <jbosscache-dev at lists.jboss.org>
>> Subject: Immutables.immutableSetCopy
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> This method looks quite inefficient for its actual usage.
>>
>> A look in the IDE shows its used by UnversionedNode.getChildrenNames()
>> and getKeysDirect(). Those pass either a ConcurrentHashMap$KeySet, a
>> FastCopyHashMap$KeySet, Collections$EmptySet or
>> Collections$SingletonSet. The attempted optimizations (some of which
>> involve reflection) in immutableSetCopy can handle non of those and
>> eventually the HashSet copy constructor gets called.
>>
>> A profiling run showed 22 invocations of UnversionedNode.getKeysDirect()
>> took 3,804 microseconds, of which 3,563 was in immutableSetCopy. 789 of
>> that was in the new HashSet(toCopy) call; the rest was basically wasted.
>>
>> Any reason I shouldn't just turn this into a new HashSet(toCopy) call?
>
> Good point, thanks for catching this. This approach works for most
> collections types where known clone methods can be faster than a new
> construction. IMO the sets you mentioned should be added to the known
> types, and handled accordingly.
>
> https://jira.jboss.org/jira/browse/JBCACHE-1535
>

Adding to the known types would be ideal. Problem is they are all 
private classes. FastCopyHashMap$KeySet could be exposed since we 
control the code, but not the others

> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat