Eelco Hillenius wrote: > > One thing I'm wondering though is whether your more efficient version > still uses introspection? If that is the case, we would love to learn > what you did to make it run more efficiently. And - if you use > introspection - ... why use introspection when you need it to run very > efficiently (just write it out directly will run much faster). > > Eelco > >
I am still using introspection because the current implementation uses property names specified in configuration files, although I may look into bypassing this. Here's how I suspect I get better efficiency: I instantiate distinct resolver objects for each property chain. When I instantiate one, I extract the getter's and setter's Method instances in the constructor. This means that when I set or retrieve the property, all I need to do is call Method.invoke(...). Since I'm sorting, I'm using the resolver for many different objects, so I don't have to retrieve the Method instance from the cache each time. (I suspect that's where I get most of the gains. HashMaps are generally pretty fast, but to improve sorting efficiency, I've found the best thing to do is speed up the individual comparisons.) (Also, since properties can be chained, I actually save an array of Getters. The longer the chain, the bigger the savings.) Earlier in this thread, Matej explained why this won't work for Wicket -- I guess your requirements are different from mine. I assume that a direct call to the property (e.g. item.getThing().getWidget().getVolume()) doesn't require anything to get cast to something else. I don't think my system would work if casting was needed, but I haven't tested that assumption. ----- 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-tp16495644p17140674.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
