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 >> >> !DSPAM:1004,45cf9f8c121927731818748! >> > > > -- > 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
