Matej Knopp-2 wrote: > > 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. 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.) ----- 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.
