commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Nistor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COLLECTIONS-415) AbstractLinkedList.removeAll() is very slow
Date Thu, 30 Aug 2012 23:00:07 GMT

    [ https://issues.apache.org/jira/browse/COLLECTIONS-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445392#comment-13445392
] 

Adrian Nistor commented on COLLECTIONS-415:
-------------------------------------------

I am attaching a patch with the javadoc clarification on the runtime
complexity of the method.  This javadoc patch is almost identical to
the javadoc added for COLLECTIONS 416 and COLLECTIONS 418.  As
discussed in COLLECTIONS 416, users should use a data structure for
the elements to be removed which supports a fast implementation of
contains.

                
> AbstractLinkedList.removeAll() is very slow
> -------------------------------------------
>
>                 Key: COLLECTIONS-415
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-415
>             Project: Commons Collections
>          Issue Type: Bug
>    Affects Versions: 3.2.1
>         Environment: java 1.6.0_24
> Ubuntu 11.10
>            Reporter: Adrian Nistor
>         Attachments: docPatch.diff, patch.diff, Test.java
>
>
> Hi,
> I am encountering a performance problem in
> AbstractLinkedList.removeAll().  It appears in version 3.2.1 and also
> in revision 1355448.  I attached a test that exposes this problem and
> a one-line patch that fixes it.  On my machine, for this test, the
> patch provides a 226X speedup.
> To run the test, just do:
> $ java Test
> The output for the un-patched version is:
> Time is 5655
> The output for the patched version is:
> Time is 25
> As the patch shows, the problem is that
> "AbstractLinkedList.removeAll(Collection<?> coll)" performs
> "coll.contains(it.next())" for each element in the AbstractLinkedList,
> which can be very expensive if "coll.contains()" is expensive, e.g.,
> when "coll" is a list.
> The one-line patch I attached puts the elements of "coll" in a HashSet
> (which has very fast "contains()"), if "coll" is not already a set:
> "if (!(coll instanceof java.util.Set<?>)) coll = new java.util.HashSet<Object>(coll);"
> Is this a bug, or am I misunderstanding the intended behavior? If so,
> can you please confirm that the patch is correct?
> Thanks,
> Adrian

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message