igor.vaynberg wrote:
>
>
>
> i still dont understand how you use propertyresolver for "sorting". is
> it that the dynamic string here represents a method that returns the
> value you sort on? to get 800ms, how big is your dataset that you are
> sorting, and how are you sorting it?
>
>
I'm using the Comparator that I put in my original post, which looks like
this:
public int compare(Object o1, Object o2) {
String property = ... ;
Object val1 = PropertyResolver.getValue( property, o1 );
Object val2 = PropertyResolver.getValue( property, o2 );
return valueComparator.compare( val1, val2 );
}
The valueComparator instance in the last line determines if the objects
implement Comparable, which they do, then casts them and calls the
compareTo() method. (In my timing results below, I simplify this by casting
them to a CollationKey without doing any tests.)
The dataset I was sorting on was generated specifically to test the speed of
different comparators, and had a dataset of 100,000 elements, and I was
sorting using the standard sort method from the collections package,
accessed from Arrays.sort(). However, I now have data that times individual
calls of the Comparator's compare() method:
Without property chaining, PropertyResolver took 16 µs, while my class took
7 µs. (I hope the mu character comes through here. That's supposed to be
microseconds.)
When I tried chaining three properties together, I got 38 µs with
PropertyResolver, and 12 µs with my approach. (I only timed getters.)
In both these cases, I'm comparing strings of only one character, so most of
the effort is spent resolving the property chains. Also, in each approach,
I'm throwing out the first use, since it spends part of its time loading
classes and caching Methods.
-----
There are 10 kinds of people: Those who know binary and those who don't.
--
View this message in context:
http://www.nabble.com/PropertyResolver-redesign-tp16495644p16576480.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
