[#GROOVY-2484] performance issue with collections operations when numbers are elements of the collections

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.6, 1.5.2

Time Tracking:

Not Specified

File Attachments:

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

[ Permlink | « Hide ]

Jochen Theodorou - 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.