> > Hi, > > > > first of all, are you sure property resolver is your bottleneck? I > > really have hard time believing that. > > > > PropertyResolver already caches the method instances based on target > > object class. > > > > Using the PropertyResolver increased my sort time from 172 ms to 875 ms, > which is roughly a factor of 5. Keep in mind that, when sorting, the > getValue() method will get called many times for each element, so it doesn't > take much to seriously slow things down. In other tests, I found that, for > example, caching a CollationKey based on the Locale also slowed things down > a lot, so I'm not surprised by this at all. > > Well, 875ms really is a lot. But i still have no idea what exactly you are doing. > > Matej Knopp-2 wrote: > > > > > > Also your approach wouldn't work for things like "property1.property2" > > where property 2 container type depends on result of property 1 > > evaluation. > > > > Unless the type of property1 changes with different instances of the > original bean, I don't see why my approach wouldn't work. Even if the type > does change, the reflection code would find the interface or abstract class > with the getProperty2() method, so it still shouldn't be a problem. (I will > write some code to test these assumptions.) No. It's called polymorphism, we can not realy on the return type.
So if you have method Object getProperty() we have to examine the return type so that we can navigate further the hierarchy, -Matej > > ----- > 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-tp16495644p16539209.html > > > Sent from the Wicket - Dev mailing list archive at Nabble.com. > > -- Resizable and reorderable grid components. http://www.inmethod.com
