Fair enough, some good points Paul. Focusing on performance is definitely a major concern as its one of the things that the end users actually sees.
I am not surprised that this has risen as an issue as geotools 2.4 has just begun to go through "release qa". Now is the time to focus on performance as we have just gotten through some major changes and things are settling down. But I think it is a mistake for us to sidestep a design that was put in place, and just add some "quick hacks" to make things fast again. Especially when the design allows us to accommodate performance. For for sure a set performance tests would have brought out this issue early and up front. Its too bad our testing infrastructure is not that sophisticated yet. Perhaps that is something we should focus on. -Justin Paul Ramsey wrote: > Perhaps I am misunderstanding the example from the users list, but > the changes to property access for wfs1.1 seem to have affected > normal renderer use, which is why the user ran across the problem. > > I was going to ask a completely orthogonal question: there are all > sorts of test cases floating around to ensure that *behavior* remains > correct through changes, but none to ensure that *performance* > remains correct, or at least "within acceptable norms". Did you > expect that your changes would impair rendering by a couple orders of > magnitude? If not, it would have been good that a test case told you > that you did, so that repairing that situation could have been your > next order of business. > > For people using Geotools as a library, predictability of performance > is just as important as predictability of API behavior. If > performance degrades by a factor of 100 after an "upgrade" they won't > say "well, at least I didn't have to change my client code" :) > > Paul > > On 11-Feb-07, at 4:37 PM, Justin Deoliveira wrote: > >> I am kind of puzzled why I am not seeing any patches for any of >> this, or >> at least a wait for some feedback. This is pretty core stuff you are >> changing, and I would like a chance to comment on it before it gets >> committed. I believe this was part of the new process we agreed on, >> no? >> >> I admit, this stuff needs some performance tuning, but that doesn;t >> mean >> it needs to be "fixed". It was not designed with performance in mind. >> The wfs 1.1. spec requires us to support xpath against features. >> This by >> design is going to not be the most efficient way of property access. >> Which is why we went to the trouble of breaking out an interface and >> extension point. So I think a bit more care is warranted. >> >> Instead of "fixing" the code that is there, I would rather you >> implement >> a different property accessor strictly for the renderer ( settable >> via a >> hint ) whose prime concern is performance. >> >> >> Andrea Aime wrote: >>> Andrea Aime ha scritto: >>>> History goes on, >>>> fixed the two above, rendering time is down to 40 seconds >>>> on java 1.4 and 6 seconds on java 1.5, which makes me think >>>> we're allocating too many objects ... investigating... >>> Oh well, I don't really know how to improve it more by quick >>> tricks, some deeper thougth is needed here. >>> What I can see, is that the worst offenders now are >>> Class.isInstance(xxx) in the Value class, Class.isAssignableFrom >>> in SimpleFeaturePropertyAccessorFactory, and the two togher >>> sum up to twice the time spent actually drawing with >>> SunGraphics2D.draw >>> (this is horrible). >>> >>> An interesting note is that the same rendering code you >>> can get on the user mailing list now takes: >>> * 24 seconds on jdk 1.4 >>> * 5.2 seconds on jdk 1.5 >>> * 3.8 seconds on jdk 1.6 >>> >>> Well, at least Sun is helping here :-) >>> Cheers >>> Andrea >>> >>> >>> >> >> -- >> Justin Deoliveira >> [EMAIL PROTECTED] >> The Open Planning Project >> http://topp.openplans.org >> >> ---------------------------------------------------------------------- >> --- >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with pre-integrated technology to make your >> job easier. >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> http://sel.as-us.falkag.net/sel? >> cmd=lnk&kid=120709&bid=263057&dat=121642 >> _______________________________________________ >> Geotools-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:1004,45cfbd38138322223018498! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
