Issue Details (XML | Word | Printable)

Key: GROOVY-2484
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Jochen Theodorou
Reporter: Olivier Nenert
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
groovy

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

Created: 09/Jan/08 02:48 AM   Updated: 17/Jan/08 07:22 AM
Component/s: groovy-jdk
Affects Version/s: 1.5, 1.5.1
Fix Version/s: 1.5.2, 1.6-rc-2

Time Tracking:
Not Specified

File Attachments: 1. Text File coco.patch (0.6 kB)


Patch Submitted: Yes


 Description  « Hide
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.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Jochen Theodorou added a comment - 17/Jan/08 07:22 AM
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.