groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-4606) Exteremely bad performance of .unique() and .unique {closure}
Date Mon, 16 Apr 2018 12:21:00 GMT

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

Paul King commented on GROOVY-4606:
-----------------------------------

Given that we now have methods like {{DGM#toUnique(List, Comparator)}} and you can use {{Comparator.naturalOrder()}}
to avoid coercion, should we close this issue or apply it as a small performance boost when
using {{unique}}? I think it would belong inside the private {{uniqueItems}} method these
days.

> Exteremely bad performance of .unique() and .unique {closure}
> -------------------------------------------------------------
>
>                 Key: GROOVY-4606
>                 URL: https://issues.apache.org/jira/browse/GROOVY-4606
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-jdk
>    Affects Versions: 1.7.5
>            Reporter: Maxym Mykhalchuk
>            Priority: Major
>         Attachments: UniqueMath.java
>
>
> DefaultGroovyMethods.unique has two inner loops, so its complexity is O(n^2)
> Practically it means that it starts taking ages on collections with 1000 or more elements.
> Simply adding elements to a linked hash set would get O(n*log n) performance.
> Will develop my own unique implementation after New Year, and will attach it here



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message