Good points Justin, Paul etc
Without any of {correct, useful, fast, reliable and maintainable}
behaviour, there is failure.
There are several requirements out in the wild:
1) point of truth - make sure you can deliver to the main infrastructure
something they can trust. This requires correctness of behaviour to be
paramount.
2) ease of use - end user is going to have a play, and start thinking
bout real requirements when they see how it works (lets face it, this is
the majority of WFS and WCS experience at the moment, but the near
future goal is these players moving to point of truth and
high-availability services.
3) high availability - performance and reliability. Typically these use
denormalised forms of the point-of truth, in a forward-caching
configuration. WMS services tend to be in this space, since WMS by
nature can provides little or no authoritative data.
It seems that to date have focussed almost exclusively on #2, as can be
seen by less-than-useful behaviour for WFS and less-than-ideal
performance for WMS.
So +1 for including performance as basis for regressive test cases. -10
for not making the code useful and maintainable in the process. It looks
like the design folks are doing a good job of decoupling the issues, but
cannot implement every possible improvement they enable immediately.
We must simply make calm, informed and pragmatic choices about how to
best use resources to fill in the gaps. IMHO we are spending far too
much time backporting key imporvements to old versions instead of
fixing reliability and performance (including tests) on the trunk.
Hacks are sometimes a very useful tactic, but when they become a
strategy its a worry.
Rob A
Justin Deoliveira wrote:
> 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!
>>
>>
>
>
>
-------------------------------------------------------------------------
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
