hmm, right
so you are running an upwards of 100K reflection lookups for the first
test, and upwards of 300K lookups in the second test. and you want
this to be performant?
sorry, but there are much better ways to sort data that do not involve
reflection. so perhaps when you come up with a realistic usecase that
shows property resolver is slow for framework usecases we will
consider tweaking it in some way.
-igor
On Tue, Apr 8, 2008 at 4:50 PM, Miguel Munoz
<[EMAIL PROTECTED]> wrote:
>
>
> 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.
>
>
