> Yes, I hoped I was making it clear that this wasn't a real-world test, it was > a stress test to exaggerate the inefficiencies. This makes them easier to > measure. Stress tests have their place.
Yeah, I got that idea :-) However, > While my code clearly wouldn't ever > see a case like this, we would see something similar: When many users are on > line, many threads will be sorting many smaller datasets. In this case, I > still want the sort to run as efficiently as possible. This is why I was > measuring the efficiency of the PropertyResolver, and why I still feel > there's a faster way to do this. Fair enough. It's certainly something to keep in mind with any flexible/ introspection based thing you do that there might be a cost. If your scale is large enough, it might be a problem. That said, I (and as is clear from that thread, 'we') don't think the efficiency of PropertyResolver is a problem, and we have in fact optimized it as much as we can within what we feel are reasonable limits (so without losing flexibility). > That said, I have accepted the Wicket team's claim that we shouldn't use > PropertyResolver in our own code. I have developed my own resolver, which, > as I expected, runs much more efficiently. (We tried OGNL and MVEL, but > neither was really suitable.) Funny enough, we started out using OGNL in early Wicket versions, but decided to create our own resolver so that we could optimize it for just our cases. What you're doing is another optimization for your situation. :-) 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
