groovy

performance issue with collections operations when numbers are elements of the collections

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.5, 1.5.1
  • Fix Version/s: 1.5.2, 1.6-rc-2
  • Component/s: groovy-jdk
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

In DefaultGroovyMethods.java, a NumberAwareComparator mimics the groovy '==' operator to compare elements against each other for collections operations such as unique(), minus(), sort() etc.
This NumberAwareComparator systematically converts any number to BigDecimal if numbers are involved slowing down very significantly those operations.
By testing first if the elements are comparable and of the same 'kind' to first compareTo() them, we get a cheap but noticeable boost.

Activity

Hide
blackdrag blackdrag added a comment -

I did not apply the patch, instead I used DefaultTypeTransformation.compareTo as base for the new implementation, which has a higher performance than the bigDecimal based widening for numbers we had before.

Show
blackdrag blackdrag added a comment - I did not apply the patch, instead I used DefaultTypeTransformation.compareTo as base for the new implementation, which has a higher performance than the bigDecimal based widening for numbers we had before.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: